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 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
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
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
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 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
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
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] [Patch] CJK autofit/autohint blue zones
Sorry for lated review. I've attached 2 PNGs: * afoff-afold-afnew_gray_wqyzh0626.png comparing 3 grayscale rasterization results for WenQuanYo-ZenHei 0.6.26 - autofit is off - old autofit (git 2011-04-18) - new autofit (git 2011-04-18 + your patch version 2.1) * afoff-afold-afnew_gray_wqyzh0945.png comparing 3 grayscale rasterization results for WenQuanYo-ZenHei 0.9.45 - autofit is off - old autofit (git 2011-04-18) - new autofit (git 2011-04-18 + your patch version 2.1) Please check if afoff-afold-afnew_gray_wqyzh0945.png reproduces the points you wanted to improve. For simplicity, I didn't apply the blurring patch for overcrowded strokes. If it is required, I will remake examples. Looking at 想意理生當着 of afoff-afold-afnew_gray_wqyzh0945.png, I think that your patch removes the bumps of surplus vertical stems crossing the lowest horizontal stems of 當着 and lifts the lowest stems of 想意 to align to the lowest stems of other glyphs. I think the bumps of surplus vertical stems crossing the lower horizontal stem (lower-right and lower-left of 口 ) is very popular design of CJK Ideographs, and they are expected to be ignored in low resolution rasterization. So the lower bluezone implementation is good to include. BTW, I'm not sure if lower bluezone should have filled/unfilled distinction. If you have any example showing the requirement, please let me know. About the other bluezones, it's difficult for me to recognize remarkable improvement. Talking about the height/width proportion of 想意, the non-autofitted results look like same size, but both (old/new) autofitted results look like different size (rather, 想 looks like as taller than 意). Also the legibility of upper parts of 它 and 當 gets worse than old autofitter. In summary, I think the lower bluezone would be worth to include in next release, but others are questionable, if my samples are appropriate to understand your proposals. Anyway, I think your approach is very good and I want to decide after complete reproduction of the demonstration. If GNU/Linux binary is acceptable, I will upload my ftstring binaries. Regards, mpsuzuki On Sat, 23 Apr 2011 10:01:23 +0200 (CEST) Werner LEMBERG w...@gnu.org wrote: There are indeed some problems with the patch. They happened when the bluezones were scaled at af_cjk_metrics_scale_dim() [...] I update the patch to the current git and address the problems. Please review the logic behind the idea. Thanks! I leave this to Toshiya-san for testing. There could be other improvements when scaling the bluezone. Like under small size, round the bluezones to the ceiling unconditionally. That could make glyph bigger and clearer. But could make it 1 pixel extra bigger than the intended size. Well, what is the `intended size'? As we all know, it's impossible to exactly find out the bbox of a glyph string without actually rendering it, and it rarely happens that you get for, say, a 10pt font at 72dpi a bbox height of 10 pixels. Additionally, bytecode instructions in TrueType fonts modify the size also, sometimes rather drastically -- in other words, I don't mind if a patch increases the size by one pixel if legibility improves, provided this size fits (more or less) with the non-CJK glyphs in the same font. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel attachment: afoff-afold-afnew_gray_wqyzh0626.pngattachment: afoff-afold-afnew_gray_wqyzh0945.png___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Any tool that visually present segments of autofit module?
On 04/24/2011 02:05 PM, Werner LEMBERG wrote:
I very much dislike the use of afhints.h and aftypes.h within the user
space. Could you instead add debug hooks to afhints.c which can be
used for communication? The simplest form could be something like
these two functions:
FT_Error
af_glyph_hints_get_num_segments(AF_GlyphHints hints,
int dimension,
FT_Int* num_segments);
FT_Error
af_glyph_hints_get_segment_offset(AF_GlyphHints hints,
int dimension,
FT_Int idx,
FT_Pos* offset);
Okey, I add the accessor functions to afhint.c.
I also made the segment drawing independent of the force autofit mode. I
found that the segment lines are useful reference with or without
autofit turned on.
One observation I had is that in order to have the outlines merge with
the segments into one, I have to
1. turn on force autofit (f)
2. turn of Horizontal and Vertical Hinting (H and V)
3. turn on hinting (h)
Otherwise, there are always some offset between the outlines and the
segments.
diff --git a/src/autofit/afhints.c b/src/autofit/afhints.c
index 70c1054..22092b0 100644
--- a/src/autofit/afhints.c
+++ b/src/autofit/afhints.c
@@ -276,6 +276,55 @@
}
#endif
+ /* Fetch number of segments */
+#ifdef __cplusplus
+ extern C {
+#endif
+ FT_Error
+ af_glyph_hints_get_num_segments( AF_GlyphHints hints,
+ int dimension,
+ FT_Int* num_segments )
+ {
+FT_Error error= AF_Err_Ok;
+AF_AxisHints axis = hints-axis[dimension];
+
+*num_segments = axis-num_segments;
+
+return error;
+ }
+#ifdef __cplusplus
+ }
+#endif
+
+ /* fetch offset of segments. User supply the offset array. */
+#ifdef __cplusplus
+ extern C {
+#endif
+ FT_Error
+ af_glyph_hints_get_segment_offset( AF_GlyphHints hints,
+ int dimension,
+ FT_Int idx,
+ FT_Pos* offset )
+ {
+FT_Error error= AF_Err_Ok;
+AF_AxisHints axis = hints-axis[dimension];
+AF_Segmentsegments = axis-segments;
+AF_Segmentlimit= segments + idx;
+AF_Segmentseg;
+
+
+for ( seg = segments; seg limit; seg++ )
+{
+ *offset = dimension == AF_DIMENSION_HORZ ? (int)seg-first-ox
+ : (int)seg-first-oy;
+ offset++;
+}
+
+return error;
+ }
+#ifdef __cplusplus
+ }
+#endif
/* Dump the array of linked edges. */
@@ -348,6 +397,27 @@
FT_UNUSED( hints );
}
+ FT_Error
+ af_glyph_hints_get_num_segments( AF_GlyphHints hints,
+ int dimension,
+ FT_Int* num_segments )
+ {
+FT_UNUSED( hints );
+FT_UNUSED( dimension );
+FT_UNUSED( num_segments );
+ }
+
+ FT_Error
+ af_glyph_hints_get_segment_offset( AF_GlyphHints hints,
+ int dimension,
+ FT_Int idx,
+ FT_Pos* offset )
+ {
+FT_UNUSED( hints );
+FT_UNUSED( dimension );
+FT_UNUSED( idx );
+FT_UNUSED( offset );
+ }
void
af_glyph_hints_dump_edges( AF_GlyphHints hints )
diff --git a/src/ftgrid.c b/src/ftgrid.c
index 711da2b..ed3a77a 100644
--- a/src/ftgrid.c
+++ b/src/ftgrid.c
@@ -57,6 +57,13 @@
extern void af_glyph_hints_dump_segments( AF_GlyphHints hints );
extern void af_glyph_hints_dump_points( AF_GlyphHints hints );
extern void af_glyph_hints_dump_edges( AF_GlyphHints hints );
+ extern FT_Error af_glyph_hints_get_num_segments( AF_GlyphHints hints,
+ int dimension,
+ FT_Int* num_segments );
+ extern FT_Error af_glyph_hints_get_segment_offset( AF_GlyphHints hints,
+ int dimension,
+ FT_Int idx,
+ FT_Pos* offset );
#ifdef __cplusplus
}
#endif
@@ -87,12 +94,14 @@ typedef struct status_
grColor on_color;
grColor conic_color;
grColor cubic_color;
+ grColor segment_color;
int do_horz_hints;
int do_vert_hints;
int do_blue_hints;
int do_outline;
int do_dots;
+ int do_segment;
double gamma;
const char* header;
@@ -116,6 +125,7 @@ grid_status_init( GridStatus st,
st-on_color = grFindColor( display-bitmap, 64, 64, 255, 255 );
st-conic_color = grFindColor( display-bitmap, 0, 128, 0, 255 );
st-cubic_color = grFindColor( display-bitmap, 255, 64, 255, 255 );
+ st-segment_color = grFindColor(
