In an earlier version of PageStream--I don't remember which, nor whether it
was V5 or V4--I had tried to use Type > Insert > Character with huge font
files including, in one case, Chinese, Japanese, and Korean.

They did not display properly in the font window. I could click on blank
spaces and get characters, but to get the one I wanted I had to try and try
again, guessing which blank space would have what I wanted.

I just tried it with 5.0.5.8a, and the display is perfect, for both of those
font files, and I can "insert visually" as the documentation puts it.

I'd hate to, say, write a Japanese sentence that way, inserting one
character, then going Type > Insert > Character and selecting the desired
font for each character, but still, it's nice to know I could.

Much of the User Documentation in that area seems perhaps dated. I couldn't
get the Alt sequences to work (e.g. Alt^E for ©, the copyright sign).
--
Bart Mathias
AmigaOne XE-G4 OS4.1u2

Greetings "Bart Mathias" <mathias@hawaii.edu>
On 06/11/2010 at 03:15 you wrote concerning
[PageStreamAmigaBeta] A (minor) plus for 5.0.5.8

Hi Bart,

<<snip>>
BM> I just tried it with 5.0.5.8a, and the display is perfect, for both of those
BM> font files, and I can "insert visually" as the documentation puts it.

BM> I'd hate to, say, write a Japanese sentence that way, inserting one
BM> character, then going Type > Insert > Character and selecting the desired w I could.

In another message, I've asked Deron if the "Insert Character" implimentation could be changed so that the "Insert Character" panel does not dissolve upon choosing the 'Insert' button. With this change, you would find the typing in Japanese much easier to do. It would also be useful to those persons who need to include many instances of 'weird' characters in their documents.

.
Cheers Don (Green Dragon)
--

On 11/5/10 9:15 PM, Bart Mathias wrote:
> In an earlier version of PageStream--I don't remember which, nor whether it
> was V5 or V4--I had tried to use Type> Insert> Character with huge font
> files including, in one case, Chinese, Japanese, and Korean.
>
> They did not display properly in the font window. I could click on blank
> spaces and get characters, but to get the one I wanted I had to try and try
> again, guessing which blank space would have what I wanted.
>
> I just tried it with 5.0.5.8a, and the display is perfect, for both of those
> font files, and I can "insert visually" as the documentation puts it.

That is good
> I'd hate to, say, write a Japanese sentence that way, inserting one
> character, then going Type> Insert> Character and selecting the desired
> font for each character, but still, it's nice to know I could.

As mentioned on the main list, I changed this behavior for the next
release. The dialog will remain open for multiple Inserts.

However, if you want to type in Japanese, then it would be best if you
used a language specific input method. I don't know if one ever actually
materialized for asian languages on the Amiga. I know at the Developer
conference in Florida they had discussions about doing some input
methods. PageStream already supported Unicode at the time, but it was
only recently (2 years ago?) that PageStream properly breaks on the
Asian word glyph boundaries. I do know that input methods exists on the
other platform we support.

It would be possible to write one on the Amiga and use arexx to send the
proper Insert command to PageStream. I realize you don't really need to
type these characters in, but someone else might.

> Much of the User Documentation in that area seems perhaps dated. I couldn't
> get the Alt sequences to work (e.g. Alt^E for ©, the copyright sign).

I don't know what user documentation you are specifically referring to!!

Deron

--
Deron Kazmaier - support@pagestream.org
Grasshopper LLC Publishing -http://www.pagestream.org
PageStream DTP for Amiga, Linux, Macintosh, and Windows

On 11/14/2010, PageStream Support wrote:

> On 11/5/10 9:15 PM, Bart Mathias wrote:
>> [...]
>> I'd hate to, say, write a Japanese sentence ... inserting one
>> character, then going Type> Insert> Character and selecting the
>> desired font for each character, but still, it's nice to know I could.
>
> As mentioned on the main list, I changed this behavior for the next
> release. The dialog will remain open for multiple Inserts.

That's good. But what you say next is more to the real point. "Insert
Character" for writing in Japanese, with several thousand characters to
hunt through, would be a real pain, even if one knows generally where to
look for each.

> However, if you want to type in Japanese, then it would be best if you
> used a language specific input method. I don't know if one ever
> actually materialized for asian languages on the Amiga. [...]

There were a couple, but problematic. I used one I wrote in ARexx to make
exams and handouts for my classes, but I never got around to making it
display choices (I'm very unsure of ARexx's graphics capabilities), so it
would give more than one character in the case of homophones, and I would
have to display it otherwise and edit out the wrong ones.

It was based on two-byte Japanese codings, one 7-bit (NewJIS), one 8-bit
(ShiftJIS), but with a bit of study I could probably redo (a copy of) one
as UTF-8.

> [...]
> It would be possible to write one on the Amiga and use arexx to send
> the proper Insert command to PageStream. I realize you don't really
> need to type these characters in, but someone else might.

The "proper insert command" may be what is crucial. OS4 comes with a
document in UTF-8 with characters from a variety of languages, including
Russian, Greek, Chinese, Korean, Japanese, etc. The document can be
imported into a PageStream page (works fine in the latest Amiga beta) and
will display all the characters that are in the currently selected font.
"Import" works, but copy and paste does not.

There are a couple of on-line word-processing programs that can be used for
inputting text in non-ASCII characters, and they work with the latest Amiga
OWB browser. I likehttp://www.gate2home.com/ for Japanese and Korean. I
thought I should be able to copy from there to PageStream, but it doesn't
quite work. For example, the Japanese hiragana normally read "ha" has the
code 0xE381AF. If I try to copy the character to NotePad, it comes out as
0xE3AF--the 0x81 is ignored. If I try to copy it to a PageStream page
instead, it comes out 0x8163812F! Even worse than NotePad.

I guess I need to find something like NotePad that doesn't ignore
non-printing characters such as 0x81. Come to think of it, I may have one.
I'll put this on hold (in case of a machine crash) while I try a hex
editor.

Hot dog! Problem solved. I have a hex editor called FileX. I copy from
Gate2Home with OWB's copy command (the regular Amiga copy puts junk in
front and changes the hex to "?"), save it to a file, and import the file
to PageStream, and voila! Terrific (too bad I'm retired and don't really
need to produce Japanese class materials anymore).

I'm going to edit the Subject line.

>> Much of the User Documentation in that area seems perhaps dated. I
>> couldn't get the Alt sequences to work (e.g. Alt^E for ©, the
>> copyright sign).
>
> I don't know what user documentation you are specifically referring
> to!!

Either /showdocs.php?id=127 or /showdocs.php?id=724# or both. There's a
suggestion that even on an Amiga one can insert special characters with ^C
or ^D and characters sequences or numbers. It doesn't work, and I jumped to
the conclusion that it doesn't work on OS4. But I suppose it is more likely
that it just doesn't work with Amiga beta 5.0.5.8, and the documentation
still stands?

By the way, the Insert Character window's gadgets (if that's the word) that
are supposed to show such codings are blank in the latest PgS5.

--
Bart Mathias
AmigaOne XE-G4 OS4.1u2

>> [...]
>> It would be possible to write one on the Amiga and use arexx to send
>> the proper Insert command to PageStream. I realize you don't really
>> need to type these characters in, but someone else might.
> The "proper insert command" may be what is crucial. OS4 comes with a
> document in UTF-8 with characters from a variety of languages, including
> Russian, Greek, Chinese, Korean, Japanese, etc. The document can be
> imported into a PageStream page (works fine in the latest Amiga beta) and
> will display all the characters that are in the currently selected font.
> "Import" works, but copy and paste does not.

I would be interested to know if they have changed the standard file
format used for copy/paste of text. It has always been IFF FTXT, which
as I understand only supports ISO ECMA Latin 1 (basically).

From the IFF FTXT spec:

Text is stored in one or more "CHRS" chunks inside an FTXT. Each CHRS
contains a stream of 8-bit text compatible with ISO and ANSI data
interchange standards. FTXT uses just the central character set from
the ISO/ANSI standards.

I could be mistaken, but I don't see a way to select another character
set, so no way to interpret the data otherwise. The clipboard certainly
allows other formats to be placed on the clipboard. Does anyone know if
a more advanced clipboard file format is supported by OWB or others?

> I thought I should be able to copy from there to PageStream, but it doesn't
> quite work. For example, the Japanese hiragana normally read "ha" has the
> code 0xE381AF. If I try to copy the character to NotePad, it comes out as
> 0xE3AF--the 0x81 is ignored. If I try to copy it to a PageStream page
> instead, it comes out 0x8163812F! Even worse than NotePad.

The problem is not the browser or PageStream, but as I said the
clipboard format used to exchange the data.

>>> Much of the User Documentation in that area seems perhaps dated. I
>>> couldn't get the Alt sequences to work (e.g. Alt^E for ©, the
>>> copyright sign).
>> I don't know what user documentation you are specifically referring
>> to!!
> Either /showdocs.php?id=127 or /showdocs.php?id=724# or both. There's a
> suggestion that even on an Amiga one can insert special characters with ^C
> or ^D and characters sequences or numbers. It doesn't work, and I jumped to
> the conclusion that it doesn't work on OS4. But I suppose it is more likely
> that it just doesn't work with Amiga beta 5.0.5.8, and the documentation
> still stands?

Ah, none of the ctrl keys work. Should be fixed in the next release.

> By the way, the Insert Character window's gadgets (if that's the word) that
> are supposed to show such codings are blank in the latest PgS5.
>

Works ok here. Only glyphs in the first 256 will show a "Key", and only
a few will show shift-control-d (control-c) short cuts.

Deron

--
Deron Kazmaier - support@pagestream.org
Grasshopper LLC Publishing -http://www.pagestream.org
PageStream DTP for Amiga, Linux, Macintosh, and Windows

Hi Deron,

On 15/11/2010, you wrote:

> I would be interested to know if they have changed the standard file
> format used for copy/paste of text. It has always been IFF FTXT, which
> as I understand only supports ISO ECMA Latin 1 (basically).
>
I just went through the release notes for clipboard.device and found no such
changes over the past umpteen years. I don't believe that it has ever
handled anything other than 8-bit characters.
>
cheers
tony

On 11/16/2010, Tony Wyatt wrote:

> [...]
> I just went through the release notes for clipboard.device and found no
> such changes over the past umpteen years. I don't believe that it has
> ever handled anything other than 8-bit characters.

I had the idea that OWB's Copy command didn't use the Clipboard. I was
wrong, but it does use it differently.

I used Gate2Home.com to write "Let's copy this" in Japanese, then copied it
two different ways. Here are the results (assuming YAM won't mess them up):

With OWB's Edit > Copy command:
ããã³ã-ããã

In Clipboards/0
00000000: 464F524D 0000004A 46545854 43534554 FORM...JFTXTCSET
00000010: 00000020 0000006A 00000000 00000000 ... ...j........
00000020: 00000000 00000000 00000000 00000000 ................
00000030: 00000000 43485253 00000016 E38193E3 ....CHRS....ã..ã
00000040: 828CE382 B3E38394 2DE38197 E38288E3 ..ã.³ã..-ã..ã..ã
00000050: 8186

With RA^C:
????-???

In clipboards/0
00000000: 464F524D 0000003C 46545854 43534554 FORM...<FTXTCSET
00000010: 00000020 00000004 00000000 00000000 ... ............
00000020: 00000000 00000000 00000000 00000000 ................
00000030: 00000000 43485253 00000008 3F3F3F3F ....CHRS....????
00000040: 2D3F3F3F -???
--
Bart Mathias
AmigaOne XE-G4 OS4.1u2

On 11/15/10 7:27 PM, Tony Wyatt wrote:
> Hi Deron,
>
> On 15/11/2010, you wrote:
>
>> I would be interested to know if they have changed the standard file
>> format used for copy/paste of text. It has always been IFF FTXT, which
>> as I understand only supports ISO ECMA Latin 1 (basically).
>>
> I just went through the release notes for clipboard.device and found no such
> changes over the past umpteen years. I don't believe that it has ever
> handled anything other than 8-bit characters.

Actually, that is not where the change would be. PageStream (and many
other applications) already put more complex data on the clipboard. It
is simply a "gentleman's agreement" that all applications put IFF FTXT
on the clipboard when they are coping text. But the clipboard allows
multiple (IFF FORM) file formats to be submitted to the clipboard in a
CAT format. That is an IFF format that allows different representation
of the same data to be stored together.

PageStream uses that ability and puts IFF FTXT & IFF CTXT to the
clipboard at the same time when you copy text. If you then paste that
selection back into PageStream you will get the full Unicode text,
formatting and everything else associated with the text selection
because PageStream will first look for FORM CTXT in the clipboard first,
and then FORM FTXT. If you paste that text from PageStream into another
application, they most likely will be looking for FORM FTXT.

PageStream also places IFF ILUS and DR2D at the same time when copying
objects. Of course, IFF ILBM is used when copy a bitmap.

This is basically the same way it works on other platforms as well.
Programs present a list of formats they can put the data to the
clipboard, and then pasting applications look for formats they can paste
starting with the "best" format and going down from there.

On the Amiga, it would be possible that others have supplemented IFF
FTXT with some kind of character set identifier (not likely since other
apps would not understand it), or they are copying some other format as
well.

Deron

> cheers
> tony

--
Deron Kazmaier - support@pagestream.org
Grasshopper LLC Publishing -http://www.pagestream.org
PageStream DTP for Amiga, Linux, Macintosh, and Windows

On 11/15/10 8:13 PM, Bart Mathias wrote:
> On 11/16/2010, Tony Wyatt wrote:
>
>> [...]
>> I just went through the release notes for clipboard.device and found no
>> such changes over the past umpteen years. I don't believe that it has
>> ever handled anything other than 8-bit characters.
> I had the idea that OWB's Copy command didn't use the Clipboard. I was
> wrong, but it does use it differently.
>
> I used Gate2Home.com to write "Let's copy this" in Japanese, then copied it
> two different ways. Here are the results (assuming YAM won't mess them up):
>
> With OWB's Edit> Copy command:
> ããã³ã-ããã
>

Ok, In IFF FTXT CHRS is the "characters". Obviously in the second one
the data is lost. It has 8 bytes, with 7 of them as question marks
($3f). The first one looks like it might have some real data. If you
selected 8 characters, then it is giving us 2 bytes per character. The
problem? That is not in the standard I don't see any reference to
the chunk CSET in any of my documentation, and certainly not something
that describes a 2 byte per glyph storage!!

I'll ask around but if anyone knows...

Deron

> In Clipboards/0
> 00000000: 464F524D 0000004A 46545854 43534554 FORM...JFTXTCSET
> 00000010: 00000020 0000006A 00000000 00000000 ... ...j........
> 00000020: 00000000 00000000 00000000 00000000 ................
> 00000030: 00000000 43485253 00000016 E38193E3 ....CHRS....ã..ã
> 00000040: 828CE382 B3E38394 2DE38197 E38288E3 ..ã.³ã..-ã..ã..ã
> 00000050: 8186
>
> With RA^C:
> ????-???
>
> In clipboards/0
> 00000000: 464F524D 0000003C 46545854 43534554 FORM...<FTXTCSET
> 00000010: 00000020 00000004 00000000 00000000 ... ............
> 00000020: 00000000 00000000 00000000 00000000 ................
> 00000030: 00000000 43485253 00000008 3F3F3F3F ....CHRS....????
> 00000040: 2D3F3F3F -???

--
Deron Kazmaier - support@pagestream.org
Grasshopper LLC Publishing -http://www.pagestream.org
PageStream DTP for Amiga, Linux, Macintosh, and Windows

Hi Deron,

On 15/11/2010, you wrote:

> I don't see any reference to
> the chunk CSET in any of my documentation, and certainly not something
> that describes a 2 byte per glyph storage!!
>
> I'll ask around but if anyone knows...
>
Nothing in the OS4 SDK...

cheers
tony

Ok Bart,

I got some information on the CSET chunk, and I think I have everything
I need to add support for this. Except for some examples. If you or
others could send me some IFF FTXT files and especially some from OWB
containing Japanese I can test the change.

Deron

-------------------------------

On 11/15/10 8:13 PM, Bart Mathias wrote:
> On 11/16/2010, Tony Wyatt wrote:
>
>> [...]
>> I just went through the release notes for clipboard.device and found no
>> such changes over the past umpteen years. I don't believe that it has
>> ever handled anything other than 8-bit characters.
> I had the idea that OWB's Copy command didn't use the Clipboard. I was
> wrong, but it does use it differently.
>
> I used Gate2Home.com to write "Let's copy this" in Japanese, then copied it
> two different ways. Here are the results (assuming YAM won't mess them up):
>
> With OWB's Edit> Copy command:
> ããã³ã-ããã
>

Ok, In IFF FTXT CHRS is the "characters". Obviously in the second one
the data is lost. It has 8 bytes, with 7 of them as question marks
($3f). The first one looks like it might have some real data. If you
selected 8 characters, then it is giving us 2 bytes per character. The
problem? That is not in the standard I don't see any reference to
the chunk CSET in any of my documentation, and certainly not something
that describes a 2 byte per glyph storage!!

I'll ask around but if anyone knows...

Deron

> In Clipboards/0
> 00000000: 464F524D 0000004A 46545854 43534554 FORM...JFTXTCSET
> 00000010: 00000020 0000006A 00000000 00000000 ... ...j........
> 00000020: 00000000 00000000 00000000 00000000 ................
> 00000030: 00000000 43485253 00000016 E38193E3 ....CHRS....ã..ã
> 00000040: 828CE382 B3E38394 2DE38197 E38288E3 ..ã.³ã..-ã..ã..ã
> 00000050: 8186
>
> With RA^C:
> ????-???
>
> In clipboards/0
> 00000000: 464F524D 0000003C 46545854 43534554 FORM...<FTXTCSET
> 00000010: 00000020 00000004 00000000 00000000 ... ............
> 00000020: 00000000 00000000 00000000 00000000 ................
> 00000030: 00000000 43485253 00000008 3F3F3F3F ....CHRS....????
> 00000040: 2D3F3F3F -???

--
Deron Kazmaier - support@pagestream.org
Grasshopper LLC Publishing -http://www.pagestream.org
PageStream DTP for Amiga, Linux, Macintosh, and Windows

Maybe this will get you started, Deron. I copied a paragraph of the Japanese
Wikipedia from OWB. I saved it to NotePad as OWBsample.utf8.

But TypeManager does not display it properly, so I think something goes
wrong when I copy it to NotePad. I notice that it lacks the "FORM ..."
stuff and gets directly to hex code.

So I tried the Clipboard version itself, as "Clipboardversion." It has the
intro stuff, but again TypeManager does not display it, and calls it
"Unicode in UTF-7"!

I'm not sure what to try next.

Bart

On 11/16/2010, PageStream Support wrote:

> Ok Bart,
>
> I got some information on the CSET chunk, and I think I have everything
> I need to add support for this. Except for some examples. If you or
> others could send me some IFF FTXT files and especially some from OWB
> containing Japanese I can test the change.
>
> Deron
>
> -------------------------------
>
>
> On 11/15/10 8:13 PM, Bart Mathias wrote:
>> On 11/16/2010, Tony Wyatt wrote:
>>
>>> [...]
>>> I just went through the release notes for clipboard.device and found
>>> no such changes over the past umpteen years. I don't believe that it
>>> has ever handled anything other than 8-bit characters.
>> I had the idea that OWB's Copy command didn't use the Clipboard. I was
>> wrong, but it does use it differently.
>>
>> I used Gate2Home.com to write "Let's copy this" in Japanese, then
>> copied it two different ways. Here are the results (assuming YAM won't
>> mess them up):
>
>> With OWB's Edit> Copy command:
>> ?????-???
>>
>
> Ok, In IFF FTXT CHRS is the "characters". Obviously in the second one
> the data is lost. It has 8 bytes, with 7 of them as question marks
> ($3f). The first one looks like it might have some real data. If you
> selected 8 characters, then it is giving us 2 bytes per character. The
> problem? That is not in the standard I don't see any reference to
> the chunk CSET in any of my documentation, and certainly not something
> that describes a 2 byte per glyph storage!!
>
> I'll ask around but if anyone knows...
>
> Deron
>
>> In Clipboards/0
>> 00000000: 464F524D 0000004A 46545854 43534554 FORM...JFTXTCSET
>> 00000010: 00000020 0000006A 00000000 00000000 ... ...j........
>> 00000020: 00000000 00000000 00000000 00000000 ................
>> 00000030: 00000000 43485253 00000016 E38193E3 ....CHRS....ã..ã
>> 00000040: 828CE382 B3E38394 2DE38197 E38288E3 ..?.??..-?..?..?
>> 00000050: 8186
>>
>> With RA^C:
>> ????-???
>>
>> In clipboards/0
>> 00000000: 464F524D 0000003C 46545854 43534554 FORM...<FTXTCSET
>> 00000010: 00000020 00000004 00000000 00000000 ... ............
>> 00000020: 00000000 00000000 00000000 00000000 ................
>> 00000030: 00000000 43485253 00000008 3F3F3F3F ....CHRS....????
>> 00000040: 2D3F3F3F -???
>
>
--
Bart Mathias
AmigaOne XE-G4 OS4.1u2

[Non-text portions of this message have been removed]

No worries. I exported/import a few different text blocks and it all
seems to work well here. You can just retest your Japanese copy/paste
with the next release. Right now when saving/copying the code will use
the default Amiga character set if it will represent the characters
selected, otherwise it will fall back to UTF-8 (which is what your
clipboard example was using). For importing/pasting, the code will
accept about 25 different character sets. If by some chance folks run
into an unsupported character set it is trivial to add it, but I doubt
that will happen if we have only now run across a need.

Evidently the cset value used in OS4 is different than what is used in
MOS, so some amount of problems can occur but since the values do not
overlap it is not a problem importing into PageStream. The only problem
would be with other apps if they don't handle both MOS and OS4 values.

Thanks for the feedback.

Deron

On 11/16/10 9:14 PM, Bart Mathias wrote:
> Maybe this will get you started, Deron. I copied a paragraph of the Japanese
> Wikipedia from OWB. I saved it to NotePad as OWBsample.utf8.
>
> But TypeManager does not display it properly, so I think something goes
> wrong when I copy it to NotePad. I notice that it lacks the "FORM ..."
> stuff and gets directly to hex code.
>
> So I tried the Clipboard version itself, as "Clipboardversion." It has the
> intro stuff, but again TypeManager does not display it, and calls it
> "Unicode in UTF-7"!
>
> I'm not sure what to try next.
>
> Bart
>
>
>
> On 11/16/2010, PageStream Support wrote:
>
>> Ok Bart,
>>
>> I got some information on the CSET chunk, and I think I have everything
>> I need to add support for this. Except for some examples. If you or
>> others could send me some IFF FTXT files and especially some from OWB
>> containing Japanese I can test the change.
>>
>> Deron
>>
>> -------------------------------
>>
>>
>> On 11/15/10 8:13 PM, Bart Mathias wrote:
>>> On 11/16/2010, Tony Wyatt wrote:
>>>
>>>> [...]
>>>> I just went through the release notes for clipboard.device and found
>>>> no such changes over the past umpteen years. I don't believe that it
>>>> has ever handled anything other than 8-bit characters.
>>> I had the idea that OWB's Copy command didn't use the Clipboard. I was
>>> wrong, but it does use it differently.
>>>
>>> I used Gate2Home.com to write "Let's copy this" in Japanese, then
>>> copied it two different ways. Here are the results (assuming YAM won't
>>> mess them up):
>>> With OWB's Edit> Copy command:
>>> ?????-???
>>>
>> Ok, In IFF FTXT CHRS is the "characters". Obviously in the second one
>> the data is lost. It has 8 bytes, with 7 of them as question marks
>> ($3f). The first one looks like it might have some real data. If you
>> selected 8 characters, then it is giving us 2 bytes per character. The
>> problem? That is not in the standard I don't see any reference to
>> the chunk CSET in any of my documentation, and certainly not something
>> that describes a 2 byte per glyph storage!!
>>
>> I'll ask around but if anyone knows...
>>
>> Deron
>>
>>> In Clipboards/0
>>> 00000000: 464F524D 0000004A 46545854 43534554 FORM...JFTXTCSET
>>> 00000010: 00000020 0000006A 00000000 00000000 ... ...j........
>>> 00000020: 00000000 00000000 00000000 00000000 ................
>>> 00000030: 00000000 43485253 00000016 E38193E3 ....CHRS....ã..ã
>>> 00000040: 828CE382 B3E38394 2DE38197 E38288E3 ..?.??..-?..?..?
>>> 00000050: 8186
>>>
>>> With RA^C:
>>> ????-???
>>>
>>> In clipboards/0
>>> 00000000: 464F524D 0000003C 46545854 43534554 FORM...<FTXTCSET
>>> 00000010: 00000020 00000004 00000000 00000000 ... ............
>>> 00000020: 00000000 00000000 00000000 00000000 ................
>>> 00000030: 00000000 43485253 00000008 3F3F3F3F ....CHRS....????
>>> 00000040: 2D3F3F3F -???
>>

--
Deron Kazmaier - support@pagestream.org
Grasshopper LLC Publishing -http://www.pagestream.org
PageStream DTP for Amiga, Linux, Macintosh, and Windows