bugThe FreeType Project - Bugs: bug #50470, No means to create unhinted size.

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #50470: No means to create unhinted size.

Submitter:  bungeman <bungeman>
Submitted:  Mon 06 Mar 2017 07:01:55 PM UTC
   
 
Severity:  3 - Normal Item Group:  Incorrect behaviour
Status:  Fixed Privacy:  Public
Assigned to:  wl Open/Closed:  Closed
Planned Release:  2.8

Jump to the original submission

Fri 28 Apr 2017 06:41:20 AM UTC, comment #26: 

Here you can find an extensive explanation of the problem.

http://lists.nongnu.org/archive/html/freetype-devel/2017-04/msg00042.html

Werner LEMBERG <wl>
Group administrator
Fri 14 Apr 2017 01:52:05 PM UTC, comment #25: 

Looking at your fine test page in Firefox, have you noticed the differences between the page and its print preview? The right waterfall edge is nice and smooth in the print preview and somewhat jagged in the actual page. So this is not exactly WYSIWYG, but not too bad.

Back to the screen problems, we got rid of rounding to integer ppem prior to autohinting. So, when somebody requested 8 points with 96 dpi, he/she asked for 10.666666 ppem. Respectfully, we now deliver narrower advances that correspond to 10.666666 ppem rather than to 11 ppem as we used to. So the real question is weather he/she meant 8 points or 8.25 points? :) He/she was not thinking that much and FreeType did not do anything wrong, did it?

Alexei Podtelezhnikov <podtelez>
Group Member
Thu 13 Apr 2017 02:47:17 PM UTC, comment #24: 

I just looked at before/after of PDF output of Chromium with both Sans and Mono fonts. The only change with the patch is the fix for the buggy kerning. No other metrics seem to change.

(file #40392)

Adam Goode <agoode>
Thu 13 Apr 2017 03:43:12 AM UTC, comment #23: 


ftview -m "HelloWorld!" -r 96 8 .../LiberationMono-Regular.ttf


This is a dramatic effect on the advance in the autohinter, which becomes much narrower than the native one.

By the way, you should test if the Chromium PDF hack works with monospace fonts, which have this unpleasant tendency to accumulate errors.

Alexei Podtelezhnikov <podtelez>
Group Member
Wed 12 Apr 2017 03:13:24 PM UTC, comment #22: 

There is at least 1 report of the height being increased after the change:
https://bugzilla.redhat.com/show_bug.cgi?id=1437999#c24

So it looks like height can go either larger or smaller depending on fonts and sizes.

Adam Goode <agoode>
Wed 12 Apr 2017 02:35:26 PM UTC, comment #21: 

The y_scale used to be adjusted twice to achieve the integer ppem first and then to fit the blue zone to the grid. The combined rounding error sometimes led to pleasantly inflated x-height. Now we omit the first step and the error is smaller actually. What is there to fix?

The blue zone rounding threshold set in aflatin.c:1175 can be increased to 52 to achieve the old appearance. Again, this inflates the x-height in comparison to the native hinter. Perhaps the native hinter is wrong too. We need to investigate this possibility before making the change.

Alexei Podtelezhnikov <podtelez>
Group Member
Tue 11 Apr 2017 10:16:55 PM UTC, comment #20: 

Alexei: thanks for tracking that down. Do you think there might be a small autohinter tweak that could be made to keep the old behavior? I think trying to preserve the existing metrics is worth it, just to avoid unnecessary churn with people's font settings.

Adam Goode <agoode>
Mon 10 Apr 2017 02:26:39 AM UTC, comment #19: 

So the pango example corresponds to

ftview -m "HelloWorld!" -r 96 11 /usr/share/fonts/dejavu/DejaVuSansMono.ttf

with light/autohint rendering. So, hinting vertically only, the autohinter switched from rounding up to rounding down. It actually looks like the switch is arbitrary (right or wrong) because the unhinted glyphs are close to the middle. The native hinter, by the way, did not change the rounding direction, which stays down. There is actually less difference between native and auto- hinters now.

The bottom line is that the problem, if any, is in the autohinter.

Alexei Podtelezhnikov <podtelez>
Group Member
Thu 06 Apr 2017 11:59:01 PM UTC, comment #18: 

Thanks, pango-view reproduces the problem nicely.

Could it be that there is some update to pango that would be needed with this fix?

Adam Goode <agoode>
Thu 06 Apr 2017 02:40:35 PM UTC, comment #17: 

Hi, I'm able to reproduce the issue by running " pango-view --dpi 96 --font "monospace 11" --text "HelloWorld!" ".

Marek Kašík <mkasik>
Wed 05 Apr 2017 10:08:46 PM UTC, comment #16: 

This is with DejaVuSansMono.ttf, probably at size 13. I only could reproduce it in Gnome, not with ftview.

Adam Goode <agoode>
Wed 05 Apr 2017 09:10:17 PM UTC, comment #15: 

We are back to square one. The rationale for the original fix in 2011 was to fix ascend, descend, and line spacing values and it worked for any font.

Alexei Podtelezhnikov <podtelez>
Group Member
Wed 05 Apr 2017 07:55:12 PM UTC, comment #14: 

I don't use Gnome, sorry.

It would be great if someone can tell me the details on font and size used in the screenshots for further analysis.

Werner LEMBERG <wl>
Group administrator
Wed 05 Apr 2017 06:23:01 PM UTC, comment #13: 

Fedora cherrypicked the patch, and some users are reporting font rendering changes (some glyphs are now vertically squashed).

See the screenshots starting at
https://bugzilla.redhat.com/show_bug.cgi?id=1437999#c9

before:
https://bugzilla.redhat.com/attachment.cgi?id=1268962

after:
https://bugzilla.redhat.com/attachment.cgi?id=1268963

Adam Goode <agoode>
Thu 30 Mar 2017 11:20:41 AM UTC, comment #12: 

My concerns were unfounded, I think.  It seems that over the years other changes fixed the metrics issues.  Just reverting the old patch appears to work just fine, so I've done it right now.

Running tests with `ftdiff' I get linear scaling for heavily hinted TTFs like `times.ttf' if rendered unhinted.  Given that TTFs without bytecode are handled automatically by the auto-hinter, I don't think there is a reason to change the handling of `face->header.Flags & 8'

Thanks for the report, and please test!  Don't hesitate to re-open this issue in case you still see problems.

Werner LEMBERG <wl>
Group administrator
Tue 21 Mar 2017 07:22:42 PM UTC, comment #11: 

No, there's a real bug, which is non-trivial to fix: Due to the copying of the rounded values in `TT_Size' to the `FT_Size' structure it is no longer possible to get real linearly scaled metrics – they are using the rounded x_scale and y_scale values...

The very problem is that the decision between rounded and unrounded metric coordinates currently happens too early (namely while setting up the size object).  However, the decision whether to get a hinted (i.e., rounded) outline or not should happen at glyph loading time – much later.

Werner LEMBERG <wl>
Group administrator
Tue 21 Mar 2017 06:52:56 PM UTC, comment #10: 

This sounds like a WYSIWYG problem: you need to somehow synchronize the layout for two devices with different resolutions, with hinting on one of them, so that both look good.

Well actually you are biased towards the PDF viewer with higher resolution. PDF viewer can actually substitute the font entirely. What then? How is it even a FreeType problem?

You just want advances for ppem=9.33 even if it looks bad on the screen. You want to have that freedom, right?

Alexei Podtelezhnikov <podtelez>
Group Member
Thu 16 Mar 2017 07:59:20 PM UTC, comment #9: 

For context, here is the original Chromium bug report:
https://bugs.chromium.org/p/chromium/issues/detail?id=696356

In this case, Chromium (via Skia) is trying to extract precise metrics and outlines from the font to produce PDF output. No rounding or hinting is desired at this stage of rendering, since the final resolution is unknown.

Later, when the PDF is viewed, hinting and rounding may occur, but that is up to the PDF viewer since only it knows the correct final device resolution.

Adam Goode <agoode>
Thu 16 Mar 2017 07:30:10 PM UTC, comment #8: 

This issue has been discussed on the mailing list, again and again.

I used to like the change because it made line spacing more consistent with the font size.

I would REALLY like to see what's not to like about discrete integer sizes.

Alexei Podtelezhnikov <podtelez>
Group Member
Thu 16 Mar 2017 03:27:36 PM UTC, comment #7: 

Thanks for the detailed report.  I agree that there is a bug.

I would like to fix that before the next FreeType release as a last task, and I ask for assistance here.  Can you write a small demo program that explicitly shows the bug (perhaps by printing metrics, etc., to stdout), together with comments that shows the expected output?

Werner LEMBERG <wl>
Group administrator
Thu 16 Mar 2017 02:49:37 PM UTC, comment #6: 

The issue here is that the rounding happens in the FT_Size, so there appears to be no way to control it. It throws away information too early. If I just want unhinted outlines or metrics out of a font that has this bit set and ask FreeType for them at a size of 9.3, FreeType won't do that because it lost the 9.3 and converted it to 9.0 before I could ask for the outlines. Since this affects the FT_Size it affects everything, not just the bitmaps.

The idea behind the 'only at integer sizes' bit is that the font designer only proofed their hints at integer sizes and wants to state that. A consequence of this is that if a font sets this bit but has no bytcode hints the bit should be completely ignored. Similarly, if one asks to load the glyph with no hinting or autohinting the bit should be ignored. In other words, this bit shouldn't cause throwing away information in the FT_Size creation, it should only affect the outlines (and phantom points) going into the bytecode hinter.

bungeman <bungeman>
Tue 14 Mar 2017 06:33:12 PM UTC, comment #5: 

Sorry about too much noise.

Do you want to ignore 'face->header.Flags & 8' if FT_LOAD_NO_HINTING?

This sounds reasonable. Werner?

Alexei Podtelezhnikov <podtelez>
Group Member
Tue 14 Mar 2017 01:52:18 AM UTC, comment #4: 

Please describe what you want to achieve.

Whatever the hinting or scaling, the bitmaps produced can only be delivered at exact pixel intervals. So the advance is always rounded in practice no matter what. There are tricks to make sure that it is rounded so that spacing between letters is distorted by less than half a pixel (read, lsb_delta and rsb_delta). I can see that LCD bitmaps, being decimated at 1/3 pixels, can be delivered at 1/3 pixel accuracy, and you can potentially devise tricks to achieve 1/6 pixel distortion in spacing. These are just theoretical constraints.

If you really want place outline origins between pixels, you are on your own: shift outlines accordingly, render them, scale the advances yourself, get to the next origin between pixels, ans so on. Notice that such layout engine cannot use cache as each rendering process is is unique on each cycle.

Alexei Podtelezhnikov <podtelez>
Group Member
Mon 13 Mar 2017 09:16:05 PM UTC, comment #3: 

Just to be clear, the fact that linearHoriAdvance doesn't work as expected is not the entire issue here (though it is part of it). The 'only at integer sizes' bit should only be respected when running bytecode hints and should be completely ignored otherwise. Even when running bytecode hints it should be ignored for anything with 'linear' in the name.

bungeman <bungeman>
Mon 13 Mar 2017 09:11:31 PM UTC, comment #2: 


>Are you aware of linearHoriAdvance?


Yes, that's what we're using, and it is also affected by this. Indeed, that's almost the entire bug.

bungeman <bungeman>
Mon 13 Mar 2017 06:16:24 PM UTC, comment #1: 

Fedora never patched it out.

Are you aware of linearHoriAdvance?

Alexei Podtelezhnikov <podtelez>
Group Member
Mon 06 Mar 2017 07:01:55 PM UTC, original submission:  

The change http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=b0962ac34e66052ccfee7996e5468f30d4bd5a72 "Fix copying metrics
from TT_Size to FT_Size if scalable font." has historically always been patched out by every distro under the sun, so this hasn't really been an issue until recently. Debian recently decided not to patch out this change, so for users it is only recently that this change has really landed.

The issue is that with this change there appears to be no way to create an 'unhinted' size. In tt_size_reset if the 'face->header.Flags & 8' is set then the size is forcibly rounded, and there doesn't appear to be any way around this. This header flag was intended for hinted fonts to request that the hints only be applied at integer sizes.

If the FreeType user wants to draw unhinted outlines which scale nicely it appears that the only way around this is to get outlines at EM size, transform them back down, and then draw from those. Also, this makes it difficult to use hinted glyphs with linear metrics as the linear metrics are now 'linear' on the rounded size instead of the requested size. At the very least it doesn't seem expected that the linear metrics should be affected by the flag in the header, since they're not part of hinting.

bungeman <bungeman>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #40392:  crbug696356.html added by agoode (5KiB - text/html)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mkasik (Posted a comment)
  • -email is unavailable- added by agoode (Posted a comment)
  • -email is unavailable- added by podtelez
  • -email is unavailable- added by wl (Posted a comment)
  • -email is unavailable- added by podtelez (Posted a comment)
  • -email is unavailable- added by agoode
  • -email is unavailable- added by bungeman (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-04-13 agoode Attached File- Added crbug696356.html, #40392
    2017-03-30 wl StatusConfirmed Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 2.8
    2017-03-16 podtelez Carbon-Copy- Added behdad
    2017-03-16 wl Item GroupWishlist Incorrect behaviour
        StatusNone Confirmed
        Assigned toNone wl
    2017-03-07 agoode Carbon-Copy- Added agoode

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code