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

Reply via email to