> > First, PS fonts don't have outline, hint, or subroutine programs.
Uh, oh, I was indeed too fast! A second reading shows that I've
written nonsense. What I've meant is that PS fonts don't contain code
which directly moves outline points; they just add suggestions to the
rasterizer how to handle the glyph or font.
> And but of course Type 1 fonts have outline, hint and subroutine
> programs!
You are right, of course.
> You can do amazing things if coding type 1 fonts by hand.
Yes, but it doesn't influence the outline itself -- a bad rasterizer
can cause horrible results even with good hints, and vice versa.
> I agree, using version numbers would be enough, but still the
> problem with lower quality remains. That's why I think that a fork
> with new names would have been wiser from the start.
The important point is `from the start'. Since this hasn't happened,
we have to urge the font designer to provide proper font versions.
> Yes, but CID fonts are really metacontainers. Inside glyph programs
> are stll organized in 8-bit chunks.
??? There is no 8bit limitation within glyph programs! The only
restriction to 8bit within PS is the size of an encoding vector, and
CID fonts don't have such a thing. Can you explain what you mean?
Maybe there is a misunderstanding. Subfonts within a CID-keyed font
can be of any size; for example, the font HiraKakuStd-W8 has 14
subfonts:
AlphaNum
Alphabetic
Dingbats
DingbatsRot
Generic
GenericRot
HKana
HKanaRot
HRoman
HRomanRot
Kana
Kanji
Proportional
ProportionalRot
`AlphaNum', has 131 glyphs, but `Kanji' contains 7075 glyphs (in my
version of the font).
> If you want to add cyrillic support to the original fonts, you can
> create font containers that only have the cyrillic glyphs properly
> named using the AGL (as you pointed out below).
Note that CFFs also can contain FontSets similar to TrueType
Collections, but this is *not* supported if you put a CFF or TTC into
an OpenType font (this is, only the first font of the collection is
addressable). BTW, only the TTC restriction is documented in the
OpenType specification, the limitation w.r.t. CFF FontSets has been
confirmed by Adobe people.
> Unfortunately not. I'm not aware of anything of that level of
> quality for the base LW35; so we need to live with what we have.
So let's wait for a new URW font release which apparently happens
soon.
> On the groff side, I think we shouldn't have problems creating
> proper virtual fonts for postscript output if the glyph containers
> were separate as outlines above. I agree that kerning is a problem
> when trying to meld separate fonts, but it could be solved by using
> modifying the existing metrics generatiion tools.
I still don't understand what you exactly mean with `glyph
containers'. CID-keyed subfonts fonts are not visible by the
end-user; the application only uses CIDs and nothing else.
BTW, I forgot to mention that CID-keyed fonts can have kerning values:
AFM files simply use CID numbers instead of a glyph names. Example
entry (from MunhwaGothic-Bold):
C -1 ; W0X 1000 ; N 1228 ; B 63 -40 833 808 ;
^^^^^^
For today's applications, AFM files are far too limited. The right
solution is to put CID-keyed fonts into an OpenType font to use its
layout features. Not supported with groff, of course :-)
Werner
_______________________________________________
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
