On 11 Dec 2002, Juliusz Chroboczek wrote:

> Sorry for mis-reading your mail, then.

  No problem :-)

> JS>   As for complex script rendering, it's possible...

> You'll doubtless agree with me that what you're describing are a
...
> for decades now -- it's high time to move on.

  Yes, I agree with you, but somebody needs to do the work.
Actually, the most difficult part may  not be programming but may be
getting/making some intelligent fonts (opentype or AAT) for complex
scripts. For Indic scripts, things are going pretty well and the number
of freely available opentype fonts for Indic scripts are increasing. For
Korean, it's not so good as I wrote before. I have yet to see a single
free opentype font.

  BTW, you'll be surprised to read comments made by some people at
<http://bugzilla.mozilla.org/show_bug.cgi?id=144663>. They want
to kill PS module in mozilla in favor of Xprint.


> JC> I'm a little bit suspicious about their choice to use Type 42 CIDFonts

> JS> Given that truetype fonts are much easier to come by than genuine
> JS> CID-keyed fonts for CJK (which is also true of truetype fonts vs PS
> JS> type 1 fonts for European scripts although to a lesser degree), I guess
> JS> the choice is all but inevitable...
>
> I may have misunderstood something, but last time I checked the
> approach was to use Type 42 CIDFonts *only*.  These are currently a
> fairly rare beast (only supported since version 3012, if memory serves).

 I also thought that's the case. However, Brian Stell changed the plan
(see http://bugzilla.mozilla.org/show_bug.cgi?id=144663. ) and he's now
gonna use type 8 (neither type 11=what you're calling type42 CIDFont =
CIDFont type2 nor type 42). What's type 8 font, btw?


> JC> [using Type 42 CIDFonts] will require many users to rasterise
> JC> everything with ghostscript on the host, with all the ensuing
> JC> performance and printing quality issues.

Because you wrote the above, I thought that you had reservation about
doing everything on the host side regarding printers as dumb devices which
may sacrifice the printing quaility. I also thought that you prefer to
leave as much as possible for PS printers to take care of. That's why I
didn't even mention the most certain way to produce portable PS output
(type3 bitmap) and I wrote about the percentage of end-users owning
PS printers.

> Conversion to Type 1 fonts works everywhere, gives excellent results,
> and the code is readily available (ttftpt1).  Finally, if everything

   Does this conversion code also work for large CJK ttf fonts(with more
than 256 glyphs)? Or, does it also support conversion to composite
font(OCF?)?

> As you see, I am not arguing against support for CIDFonts; I'm merely
> stating that making Type 42 CIDFonts the only download format for TTFs
> makes me er... suspicious.

  I'm not against producing portable PS, either :-).  However,
I think the portability of PS output doesn't matter much considering
the way printing is handled these days in Unix/Linux.

   Jungshik

--
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/linux-utf8/

Reply via email to