Re: Help converting a truetype unicode font to type3
On Aug 26, 12:30 am, ken <k...@spamcop.net> wrote:
> In article <_gCsk.12225$Rs1....@newsfe08.iad>, maxi...@microsoft.com
> says...
>
> > Thank you for the help. I played Ken's script a little bit, and found that
> > it is not possible to cache a big font in the printer. The printer shows Max
> > Glyph Size as 25K, and max cached glyphs as 7K. The numbers are just too
> > small.
>
> Those are 'odd' numbers, the maximum size of a sinlge glyph appears to
> exceed the maximum set aside for caching glyphs...
>
> But as I said, I doubt if this is your problem. Its unlikely the bitmap
> is very large and even if it is the glyph would normally simply be
> rendered direct from the glyph program, without recourse to the cache.
>
> Slow, but robust.
>
> I suspect the problem is the size of the font cache, which you may yet
> be able to alter.
>
> Again you could experiment with this by creating fonts containing
> different numbers of glyphs and see where they stop working.
>
> > After some search, it is mentioned that CID type 1 (type 10?) format can
> > encode a type3 font with larger encoding range. However, I am unable to find
> > an example. Any ideas?
>
> The Encoding range is really down to the internal representation of the
> font. In your original post you said you had been using compostie fonts
> originally, but these didn't work. CIDFonts are an alternatvie to
> composite fonts which are easier to use, but are no substantially
> smaller. If composite fonts didn't work I doubt CIDFonts will.
>
> However, if you want to experiment with CIDFonts, you don't need to go
> to type 3. You can use a CIDFontType 2 with a FontType of 11, which uses
> TrueType outlines directly. (p377 of the third edition PLRM)
>
> This assumes, of course, that your printer is level 3 and supports
> CIDFonts.
>
> Ken
You can create a Type 0 font with Type 3 daughter fonts. The BuildChar
procedure in the Type 3 daughter fonts can then call Type 42 fonts to
render the actual glyphs. I did this fifteen years ago and it worked.
There was a problem with older printers having a 500-point limit on
the path; Adobe upped this to 1500 points for CJK implementations and
then kept it there for Level 2, I think. What version of PS is in the
printers you are targeting? And you have to make sure all the daughter
fonts and Type 42 fonts have unique UniqueID's (obviously) or you'll
mess up the cache.
How can you be sure exactly what is causing the error? Can you tell us
the error message exactly? That means not only 'error name' but also
'offending command'. I thought if you try to make a string bigger than
64K, you get a rangecheck error, not an out-of-memory error. If you
try to execute PS code that tries to build an array containing 10,000
64K strings, then I could see you getting an out-of-memory error. Get
some more data, compare available VM in GhostScript vs. your printers:
vmstatus 3 1 roll pop pop (VM max: )print = flush
Maybe not all Type42 implementations are the same (i.e. GhostScript
vs. your printers). You mentioned all the SFNT strings are in one
array, shared by the Type42 daughter fonts. Well, maybe the Type42
implementation is trying to load that whole array into memory each
time it renders a glyph, instead of just loading the required strings
from within that array? In that case, you'll have to break up that big
array into smaller SFNT arrays, let's say one for each daughter font.
Alternatively, if you use Type 3 fonts to call Type 42 fonts, you can
have the code in the Type 3 BuildChar load only the necessary SFNT
data for the Type 42 font it is calling (or temporarily rename a
smaller SFNT array to the name that the Type 42 implementation expects
at render-time).
To test your assumption, try rendering the same CJK characters in
different fonts, for example, in Japanese, a Gothic compared to a
Mincho. Gothic is like our sans-serif and Mincho is like serif, so a
Mincho outline is much more complicated than a Gothic, and should run
out of memory faster, if that's really your problem. Chinese and
Korean also have simpler/more complex font styles that you could use
to compare memory usage in this way. Traditional Chinese has some
super-complex glyphs, if you should happen to have one of those fonts
lying around.
Finally, if you have a BuildChar or BuildGlyph implementation
somewhere in your code, put in some debugging code:
vmstatus pop exch pop (VM used: )print = flush
or if you don't have feedback (2-way comm with printer) then you'll
have to print that value out on the page somewhere. At least you
should be able to see when and where all the memory is getting eaten
up. Is it in the call to the very first CJK glyph? Or does the
interpreter get a few lines into the page before it blows up?
-David
Fnews-brouse 1.9(20180406) -- by Mizuno, MWE <mwe@ccsf.jp>
GnuPG Key ID = ECC8A735
GnuPG Key fingerprint = 9BE6 B9E9 55A5 A499 CD51 946E 9BDC 7870 ECC8 A735