| Summary: | Glyph size/appearance errors | ||
|---|---|---|---|
| Product: | freetype | Reporter: | Jethro Beekman <freedesktop-bugs> |
| Component: | general | Assignee: | Werner Lemberg <wl> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | freedesktop, ismo.toijala, rdfzc14 |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Compile with gcc -I/usr/include/freetype2 -I/usr/include/cairo cairo_xlib_simple.c -lcairo -lX11 -lfreetype
Font file that exhibits the rendering error Incorrect render #1 Incorrect render #2 Correct render #1 Correct render #2 updated cairo-based test case |
||
|
Description
Jethro Beekman
2015-08-31 20:23:33 UTC
Created attachment 118022 [details]
Font file that exhibits the rendering error
Created attachment 118023 [details]
Incorrect render #1
Example of an incorrect rendering.
Ubuntu 14.04
Cairo version 1.13.0~20140204-0ubuntu1.1
Freetype version 2.5.2-1ubuntu2.4
Created attachment 118024 [details]
Incorrect render #2
Example of an incorrect rendering. This screenshot was taken with the X server on Ubuntu 14.04 and client on Red Hat 5.11, X forwarding over SSH.
Red Hat 5.11
Freetype 2.2.1-32.el5_9.1
Cairo 1.2.4-5.el5
Created attachment 118025 [details]
Correct render #1
This is an example of a correct rendering. This screenshot was taken over NX.
Red Hat 5.11
Freetype 2.2.1-32.el5_9.1
Cairo 1.2.4-5.el5
I should mention the bug remains on Ubuntu when tested with vanilla Freetype 2.6 and Cairo 1.14.2. Created attachment 118026 [details]
Correct render #2
Example of a correct rendering. This was created using the Image surface.
Ubuntu 14.04
Cairo version 1.13.0~20140204-0ubuntu1.1
Freetype version 2.5.2-1ubuntu2.4
Clarification on the attachements: Attachment #118021 [details] is named cairo_xlib_simple.c Attachment #118022 [details] is an OTF file named cmex10.otf Attachment #118025 [details] is a PNG file Test case crashes for me. Will take a look later. Ok, doesn't crash anymore, but all I see is a black window. Ok I can reproduce after adding cairo_surface_flush(). This is a FreeType autohinter issue. The font in question has a root-sign at letter 's'. Bug only exists if hinting-mode=slight is chosen. That invokes autohinter in vertical direction only. If you try other hinting modes (NONE, MEDIUM, FULL) bug doesn't appear. Can be reproduced using ftview. Press 'f' to force autohinting on, then arrow-key up/down and see how the shape jumps drastically at some point sizes... Created attachment 118032 [details]
updated cairo-based test case
It's a font *and* PDF engine bug. The font contains a cmap that maps position `r' (not `s', BTW) to a glyph called `.notdef'. Since the auto-hinter accesses a font not by glyph names but by a Unicode mapping (either a real one or a synthesized), it believes that glyph `r' is present, which accidentally is one of the glyphs used for deriving blue zones of the latin script. This fact makes the auto-hinter proceed, which fails miserably. Two important rules. (1) Font cmaps must not lie to the auto-hinter! (2) In general, don't use the auto-hinter for rendering sub-setted fonts! As this example shows, such fonts are often buggy since the character to glyph mappings are extremely simplified, making it impossible for the auto-hinter to derive sensible global glyph information. I believe the problem is that the TeX math fonts use non-Unicode mappings. That's the part about being a font bug. However, even then, autohinter should NOT do crazy stuff like this. The 'r' could be from a cursive handwritten font with huge extents... > However, even then, autohinter should NOT do crazy stuff like this.
> The 'r' could be from a cursive handwritten font with huge extents...
The auto-hinter normally doesn't rely on a single character to derive blue-zones! In practice, such extreme behaviour can only be seen for incorrect cmaps and not enough sample glyphs to derive the global data, so your argument doesn't hold IMHO.
I might modify the auto-hinter to reject hinting if there is just a single glyph. However, the font here in question is simply buggy, and in most cases the cmap *is* valid. By the way, any font that has an incorrect cmap gets rendered badly with the auto-hinter, regardless of the number of available glyphs...
On the other hand, I agree it would be a nice project to limit vertical movements done by the auto-hinter. Please open a `wishlist' bug report! I don't know much about fonts. Are you sure there is an issue with the PDF as well? It might just be an issue with Type 1 -> OpenType conversion. I attached the PDF-embedded Type 1 font to the Firefox bug. I don't know how adapt the testcase to render that (using that in FT_New_Face results in nothing being drawn). Oh it's probably pdf.js's fault partially as well, perhaps the bogus cmap is comping from pdf.js, not from the original font. Someone needs to verify. The original file `cmex10.pfb' (version 003.002) as delivered with TeXLive has a correct encoding vector, using glyph name `radicalbigg' at position 0x72. The subsetted `CMEX10.pfb' file in the FireFox bug report also has the correct glyph name. (In reply to Werner Lemberg from comment #17) > On the other hand, I agree it would be a nice project to limit vertical > movements done by the auto-hinter. Please open a `wishlist' bug report! I did this just now. https://savannah.nongnu.org/bugs/index.php?46195 This should now be fixed in FreeType's git repository, please test. http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=be32b168ac42e670e1a8c5c614cce4c3f8232829 Works, thanks! Unfortunately, my distro's FreeType is too old (2.5) to easily backport the patch (y_offset is not defined). |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.