Just some details what each approach will produce: #1 produces a /CIDFontType0 CIDFont [1] and a /Type0 Composite Font referencing the former.
#2 produces one or more /Type1 fonts. [1] for TrueType we produce a CIDFontType2 CIDFont and a /Type0 Composite font for each TrueType font. OpenOffice produces one or more /TrueType fonts for each TrueType font. #1 would always generate a CID font for simplicity. What you propose is basically a "#2a", i.e. produce a /Type1 font if the document stays within the default encoding of the font. If additional characters are used FOP would switch to CID fonts instead of producing a /Type1 font. So this needs elements from #1 and #2. Possible and probably makes sense if CID fonts work in the first place. I like it. BTW, I just found out that I have to generate a ToUnicode CMap if a Type1 font doesn't use one of the encodings that are predefined in the PDF spec. So a little more work for me there. On 13.02.2008 11:57:34 Vincent Hennebert wrote: > Hi Jeremias, > > With solution #1, if I happen to use only the glyphs from the font that > are available in its default encoding, will the resulting PDF be the > same as in solution #2? > What I mean is, will feature-incomplete PDF readers be able to display > it? In which case this wouldn’t be that bad. > > Anyway, solution #1 also looks cleaner to me, so go for it. If that > means that I’ll have to create a RFE for my favourite PDF reader, then > I’ll do it ;-) > > Vincent > > > Jeremias Maerki wrote: > > I've been asked to look into the possibility to support unusual > > encodings (like Cyrillic) with Type 1 fonts. Right now we only support > > WinAnsiEncoding (plus special handling for Symbol and ZapfDingbats). > > > > I already have an AFM parser. The AFM parser is the precondition to > > safely support non-standard encodings as only this file contains the > > glyph list of a font. > > > > I'm now on a good way to support non-WinAnsi encodings since I can now > > build CodePointMapping instances from an AFM file. I then have to teach > > the PDF and PS renderers to make use of these special encodings. > > > > That's step 1, but it will only make the font's native encoding > > available in FOP. The number of available glyphs for a Type 1 font will > > still remain under 255 (typicaly under 223 as the first 32 chars are > > usually not used). To support all glyphs of a Type 1 font we need more > > and I found two possible ways to pursue: > > > > 1. Treat Type 1 fonts as CID fonts. > > > > + Probably the cleaner approach. > > + All glyphs are supported under one single font (no font renderer-level > > font switching required, see below) > > - Makes the generated PDF/PS code a little less readable but that's not > > important. > > > > 2. Do something like OpenOffice when handling fonts with more than 255 > > chars: Create multiple single-byte encodings which map to the same base > > font. This will require an 1:n relationship from font to char mapping > > which the renderers also have to handle. The first encoding will be > > equal to the font's default encoding (PDF calls that the "implicit base > > encoding"). The other encoding(s) will be built from the rest of the > > available characters. In the renderer it will be necessary to switch > > fonts from one character to another (not the same as switching from > > Helvetica to Symbol, i.e. not at FO level, but at renderer level). > > > > + Higher compatibility with PDF viewers which are not yet > > feature-complete. > > + Keeps the generated PDF/PS code more readable (not important) > > - Switching between derived fonts (i.e. font with a common base font but > > with special encodings) is necessary. SingleByteFont needs to be split > > in two classes. > > > > An example: The "Baskerville Cyrillic" font contains 264 > > characters/glyphs. The default encoding only contains 221 characters. So > > 43 additional characters can be made available like this. > > > > I'm currently leaning towards CID fonts as it is probably the cleaner > > approach. Both solutions are probably pretty much the same in terms of > > effort. The CID approach will take more work in the PS renderer and the > > multi-encoding approach will make changes necessary in FOP's font > > library. > > > > If anyone has thoughts on this, I'd appreciate it. I'll finish the > > changes for supporting the default encodings and then finish the > > processing feedback stuff before I finish this here. > > > > Jeremias Maerki > > > -- > Vincent Hennebert Anyware Technologies > http://people.apache.org/~vhennebert http://www.anyware-tech.com > Apache FOP Committer FOP Development/Consulting Jeremias Maerki
