Hi Ruud, Yes this is a bug, which has been fixed in my patch, but since I didn't think anyone else had bumped into it I didn't want to put it into trunk since I also made some code improvements to the class and was weary that it could cause merge issues when/if the branches are merged.
The issue is that in most fonts the first 3 glyphs are set to .notdef, and this was implemented in FOP. However, the spec says only the first glyph is reserved for .notdef, and what happens in MOST fonts doesn't happen in ALL fonts. If you create a bug report, I'll attach a patch and hopefully it'll be fixed fairly promptly. Hope that helps Mehdi On 2 May 2011 10:12, ruud grosmann <r.grosm...@gmail.com> wrote: > On 02/05/2011, ruud grosmann <r.grosm...@gmail.com> wrote: > >> It appears that in the ToUnicode table that goes with the fonts, the >> space character maps to unicode ffff. > > > maybe I should say that I mean the ToUnicode table that accompanies > the subset font in the PDF that is generated by fop. > > I have attached the original PDF where the other attachments are > extracted from. More specially, PDF objects 73 and 78. These contain > the fontfile of (a subset from) the bold font that is used in the > document and the ToUnicode table. > > best regards, Ruud > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
