Re: [ft-devel] Registration of a set of trickyfonts by NEC

2011-04-28 Thread suzuki toshiya
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

2011-04-28 Thread Werner LEMBERG
 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

2011-04-28 Thread Miles Bader
suzuki toshiya mpsuz...@hiroshima-u.ac.jp 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

2011-04-28 Thread mpsuzuki
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 mi...@gnu.org wrote:

suzuki toshiya mpsuz...@hiroshima-u.ac.jp 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

2011-04-28 Thread david.bevan

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 mi...@gnu.org wrote:

suzuki toshiya mpsuz...@hiroshima-u.ac.jp 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

2011-04-28 Thread Werner LEMBERG

 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

2011-04-28 Thread mpsuzuki
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 w...@gnu.org 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

2011-04-28 Thread mpsuzuki
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 w...@gnu.org 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

2011-04-28 Thread suzuki toshiya
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 mi...@gnu.org wrote:
 
 suzuki toshiya mpsuz...@hiroshima-u.ac.jp 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

2011-04-27 Thread Werner LEMBERG

 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