Re: [ft-devel] Registration of a set of trickyfonts by NEC
> Considering that the number of blacklist is increased to 13, I > changed the algorithm to compare the checksums slightly. > > It seems that the fonts are not so popular, so this is not urgent > issue. Please give me comment. Your patch looks fine. I haven't tested actually whether it works, but i trust you :-) Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Registration of a set of trickyfonts by NEC
Oops, my proposal was insufficient because it was proposed without samples to reproduce the issue. Just I've posted sample PDF at: https://savannah.nongnu.org/patch/download.php?file_id=23313 It seems that no objection against the change of algorithm to lookup a tricky font, I will apply my patch. BTW, during the production of sample PDF, I found that OpenOffice.org generates wrong checksum for embedded TTF, so the tricky font detection by the checksum cannot solve the problem :-( Regards, mpsuzuki Werner LEMBERG wrote: >> Considering that the number of blacklist is increased to 13, I >> changed the algorithm to compare the checksums slightly. >> >> It seems that the fonts are not so popular, so this is not urgent >> issue. Please give me comment. > > Your patch looks fine. I haven't tested actually whether it works, > but i trust you :-) > > > Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Registration of a set of trickyfonts by NEC
> BTW, during the production of sample PDF, I found that > OpenOffice.org generates wrong checksum for embedded TTF, so the > tricky font detection by the checksum cannot solve the problem :-( Uh, oh. Please write a bug report to the OpenOffice/LibreOffice people. It seems to me that we can't do more on the FreeType side to make the fonts work. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Registration of a set of trickyfonts by NEC
suzuki toshiya writes: > BTW, during the production of sample PDF, I found that > OpenOffice.org generates wrong checksum for embedded TTF, > so the tricky font detection by the checksum cannot solve > the problem :-( Could you compare against _both_ the real checksum and the bogus OpenOffice.org checksum, and recognize both? [Maybe just add separate entries for the "bogus OpenOffice.org version" of these fonts...] -Miles -- The automobile has not merely taken over the street, it has dissolved the living tissue of the city. Its appetite for space is absolutely insatiable; moving and parked, it devours urban land, leaving the buildings as mere islands of habitable space in a sea of dangerous and ugly traffic. [James Marston Fitch, New York Times, 1 May 1960] ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Registration of a set of trickyfonts by NEC
Yes, I should file the bug with yet another sample with free fonts (NEC FA-xxx fonts are proprietary) including the clarification you commented. Regards, mpsuzuki On Thu, 28 Apr 2011 18:23:32 +0900 Miles Bader wrote: >suzuki toshiya writes: >> BTW, during the production of sample PDF, I found that >> OpenOffice.org generates wrong checksum for embedded TTF, >> so the tricky font detection by the checksum cannot solve >> the problem :-( > >Could you compare against _both_ the real checksum and the bogus >OpenOffice.org checksum, and recognize both? [Maybe just add separate >entries for the "bogus OpenOffice.org version" of these fonts...] > >-Miles ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Registration of a set of trickyfonts by NEC
For some reason I assumed that FreeType would be calculating the checksum. I'm sure there's lots of code that doesn't bother to set the checksums at all. David %^> -Original Message- From: freetype-devel-bounces+david.bevan=pb@nongnu.org [mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of mpsuz...@hiroshima-u.ac.jp Sent: 28 April 2011 10:30 To: freetype-devel@nongnu.org Cc: Miles Bader Subject: Re: [ft-devel] Registration of a set of trickyfonts by NEC Yes, I should file the bug with yet another sample with free fonts (NEC FA-xxx fonts are proprietary) including the clarification you commented. Regards, mpsuzuki On Thu, 28 Apr 2011 18:23:32 +0900 Miles Bader wrote: >suzuki toshiya writes: >> BTW, during the production of sample PDF, I found that >> OpenOffice.org generates wrong checksum for embedded TTF, >> so the tricky font detection by the checksum cannot solve >> the problem :-( > >Could you compare against _both_ the real checksum and the bogus >OpenOffice.org checksum, and recognize both? [Maybe just add separate >entries for the "bogus OpenOffice.org version" of these fonts...] > >-Miles ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Registration of a set of trickyfonts by NEC
> For some reason I assumed that FreeType would be calculating the > checksum. I'm sure there's lots of code that doesn't bother to set > the checksums at all. The problem are subsetted fonts, I believe. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Registration of a set of trickyfonts by NEC
One of the possibility (workaround for OOo) is the extension of the tricky font detection by the name. At present, only family name is compared, additional checking PostScript name may be helpful for this issue. OOo retains the name table (which is optional in Type42 spec), so MingLiU can be detected correctly. Unfortunately, NEC FA-xxx family have no name entries tagged as "English" for family name, there are only non-ASCII Japanese family names in the font. So the tricky font detection by family name is difficult. The family name in FT_Face object includes broken Shift-JIS string. It is possible to register broken Shift-JIS strings as tricky font name lists, but there is a possibility of off-target strike. In such fonts, still PostScript name is written in ASCII, so I think the checking PostScript name is easier. However, current sfnt_get_ps_name() does not check the name string if it is not declared as Microsoft/ UCS2/English-US or Apple/Roman/English. I will propose some patch to add a fallback to other ASCII PS names. # In fact, Microsoft/UCS2/English-UK, Microsoft/UCS2/ # English-Australia etc would be good candidates for # fallback, although I'm suspicous if a font with # English-UK but without English-US is popular. Regards, mpsuzuki On Thu, 28 Apr 2011 09:11:40 +0200 (CEST) Werner LEMBERG wrote: >> BTW, during the production of sample PDF, I found that >> OpenOffice.org generates wrong checksum for embedded TTF, so the >> tricky font detection by the checksum cannot solve the problem :-( > >Uh, oh. Please write a bug report to the OpenOffice/LibreOffice >people. It seems to me that we can't do more on the FreeType side to >make the fonts work. > > >Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Registration of a set of trickyfonts by NEC
Ah, Bevan's proposal is reasonable... I selected 3 Type42-required subtables (cvt/fpgm/prep) which are very difficult to subset without detailed interpretation of glyf program. So, even if the embedded fonts are subsetted, usually they are same with original fonts. # If they are modified, it means that the embedder should # have some TrueType instruction interpreter, so I want # the embedder to care about the hinting. And, FT2 has builtin checksum calculater. In fact, some PDF generators don't write the checksum at all (maybe they don't want spend CPU cycles to recalculate checksums for subsetted tables like loca, glyf, etc), in such case, FT2 calculate the checksum by itself. When I designed so, I was thinking that most TrueType embedders may calculate the checksum correctly, or copy the checksum, or leave the checksum as 0x, so, skipping the checksum recalculation for non-zero value makes the tricky font checking faster. In fact, now, the trickyness check by the checksum is executed for most non-tricky TrueType fonts (it's ironic!) Anyway, my assumption might be wrong. I should check the cost of checksum recalculation by some benchmarks... Regards, mpsuzuki On Thu, 28 Apr 2011 11:43:13 +0200 (CEST) Werner LEMBERG wrote: > >> For some reason I assumed that FreeType would be calculating the >> checksum. I'm sure there's lots of code that doesn't bother to set >> the checksums at all. > >The problem are subsetted fonts, I believe. > > > Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Registration of a set of trickyfonts by NEC
Just I've uploaded an archive: http://gyvern.ipc.hiroshima-u.ac.jp/~mpsuzuki/ooo-ttf-checksum-test.zip it includes following files: * LiberationSerif-Regular.ttf - a free font including cvt/fpgm/prep tables * LiberationSerif.odt - an ODT document referring LiberationSerif font * LiberationSerif-OO3.pdf - a PDF generated by LibreOffice 3.3.1 to be precisely, OOO330m19 (Build:8) tagged libreoffice-3.3.1.2, Debian package (1:3.3.1-1) * embedded-font.pdf - subsetted & embedded font in the PDF I think this is not Debian specific issue, but reporting the issue by Debian binary to LibreOffice official maintainers won't be welcomed. I will make more official style report for their official bugzilla. But I have to work with other issues before it... Regards, mpsuzuki mpsuz...@hiroshima-u.ac.jp wrote: > Yes, I should file the bug with yet another sample > with free fonts (NEC FA-xxx fonts are proprietary) > including the clarification you commented. > > Regards, > mpsuzuki > > On Thu, 28 Apr 2011 18:23:32 +0900 > Miles Bader wrote: > >> suzuki toshiya writes: >>> BTW, during the production of sample PDF, I found that >>> OpenOffice.org generates wrong checksum for embedded TTF, >>> so the tricky font detection by the checksum cannot solve >>> the problem :-( >> Could you compare against _both_ the real checksum and the bogus >> OpenOffice.org checksum, and recognize both? [Maybe just add separate >> entries for the "bogus OpenOffice.org version" of these fonts...] >> >> -Miles > > ___ > Freetype-devel mailing list > Freetype-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Registration of a set of trickyfonts by NEC
I've registered a set of NEC FA family to tricky font list, in git head. On Thu, 28 Apr 2011 15:21:00 +0900 suzuki toshiya wrote: >Oops, my proposal was insufficient because it was proposed >without samples to reproduce the issue. Just I've posted >sample PDF at: >https://savannah.nongnu.org/patch/download.php?file_id=23313 > >It seems that no objection against the change of algorithm >to lookup a tricky font, I will apply my patch. Considering the benchmark results that the table length comparison before the checksum comparison reduces the times of the checksum calculation, I have not changed the algorithm but add extra checking to assure that 0-length table in the registry is not included in the font. The algorithm proposed in my first post of this thread: http://lists.gnu.org/archive/html/freetype-devel/2011-04/msg00081.html was making a concatenated checksum of cvt/fpgm/prep from given font (regardless with the content in the registry of tricky fonts) and compare it with the entries in the registry by simple memcmp(). There is a proposal to ignore the checksum in the header to prevent the influences from incorrect TrueType embedders. If it is agreed (Werner had already commented "it is acceptable"), my previous proposal forces the recalculation and makes the tricky font checking expensive, so I kept original algorithm to compare the registered fonts and the given font. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel