[scribus-dev] GSoC Updates

[Andreas Vox]

Hi Pierre! 
 
> -----Ursprüngliche Nachricht-----
> Von: scribus-dev-bounces at lists.scribus.net 
> [mailto:scribus-dev-bounces at lists.scribus.net] Im Auftrag 
> von Pierre Marchand
> Gesendet: Donnerstag, 2. Juli 2009 18:02
> An: Thach Tran; 'Scribus Development Mailing List'
> Betreff: Re: [scribus-dev] GSoC Updates
> 
> Vous (Thach Tran) avez écrit :
> > Hi,
> >
> > I have solved the TrueType embedding problem in PDF/X-4. 
> What I did is 
> > I embedded it as a Type0 font (CID font).
> 
> I finally found time to read your code and think a bit more 
> about it? I must say I’m not exactly excited by tricking the 
> font type.
 
Any specific reason?
 
> After looking again at PDF ref. (1.3) I would suggest to do 
> things the simple way. As in following instructions given for 
> TrueType fonts regarding encoding (p. 307 and ff). First of 
> all, it’s clearly stated that Differences array is not 
> recommended for TT fonts, so nothing new in fact. p. 310 
> gives us 3 possibilities to map char code as found in strings 
> to glyph index. None of them is impossible to use inside the 
> Scribus pdflib. What we need is to add few methods to 
> ScFace_ttf in order to check the presence of 
> platform/encoding pairs, and maybe check the validity of the 
> cmap table. Plus, we want to check if the glyph index we get 
 
The problem is that those are 8 bit encodings, limited to Latin
characters. If we want to access all glyphs in a font, we need
to change its encoding. For TT fonts, that means either using a
nonsymbolic font with Differences (not recommended) or using a
CID encoding. 
 
In my view, using the Differences method or trying to cherry-pick 
the correct cmap in the font (which only gives us (1,0) or (3,1)
for nonsymbolic fonts or (3,0)/(1,0) for symbolic fonts) is not
reliable enough and would need font anaylsis and complex code.
The CID way is a well-defined and should work for any TT font. 
Compared with Type1 fonts we don't even need the current multiple
224 chars encodings Scribus produces now. Instead we can use a single
Cmap for the font. Best of all, the application that reads the 
PDF has no choice how to do the mapping - no surprises possible.
 
For Type1 fonts, the CID way is not so easy, since Type1 CID fonts
use the CFF format. Here the current approach with multiple 224 chars
encodings seems best. For Type3 fonts there isnt any choise anyhow.
 
> through AGL leads to the same index as selected by Freetype 
> for the very same codepoint. 
> 
> Case 1,  all is fine, got the right platform/encoding, got 
> good indexes for charcodes, etc, we embed the font as is and 
> that’s it (well, write the correct Font dictionary:)
> 
> Case 2, there’s no cmap with 3/1 or 1/0, I would tend to not 
> embedded  the TT font at this point. Means outline it in a Type3.
> 
> Case 3, glyph indexes as returned by AGL are not the same as 
> returned by
> Freetype: a) if there’s a cmap 1/0, check if possible to 
> follow same instructions as for symbolics fonts (no Encoding 
> dictionary at all) b) else, outline again.
> 
> I haven’t considered the possibility to alter the string 
> itself to fit in a particular encoding. You can explore it 
> but really it would be nice to achieve clean embedding 
> without hack elsewhere :)
> 
We already do that with our 224 chars encodings. 
 
> This work would benefit generally for TTF embedding and I’ll 
> be available to help writing or write myself needed methods in ScFace.
> 
> What do you think?
 
I think Thach did a great job! :-)
 
/Andreas