Thu 13 Jul 2017 08:29:30 AM UTC, comment #5:
`tt_size_reset' with the `only_height' flag set is special code for variation fonts. At the time of calling this function, `x_scale' and `y_scale' are already computed for TrueType fonts – it would be an error to recompute those values again after the `MVAR' table data is applied.
I've added a comment to the source code.
|
Thu 13 Jul 2017 06:39:14 AM UTC, comment #4:
I see that I actually referred to the wrong commit in the ticket for my second point (although referred to the correct one in patch 0001).
So, to remove any doubt, I was referring to 8ab08cff63eeb23b6c9f2c4470ae9809f2acf244.
This commit has no mention of a different rounding scheme, nor it shows it uses a different one.
What it does (as I see it) is that it returns after the y-related calculations, if 'only_height' is set.
This looks innocent enough, but what it did was to also move the y_scale value calculation, on which all the height calculations depend.
So, to refine my question: if this is intentional, for the calculation 'FT_PIX_ROUND( FT_MulFix( face->root.ascender, metrics->y_scale ) );', and considering y_scale is only calculated *after* this line, which y_scale value is used here?
Again, appreciate all the help.
|
Wed 12 Jul 2017 07:59:53 PM UTC, comment #3:
> So, my question is: why are the x and y cases different?
You left out the most important part: The rounding, which is different to the standard rounding FreeType is using. These rounded x and y values define new, adjusted horizontal and vertical scaling values! Consequently, the maximum advance value has to be computed later on with the adjusted scaling values.
> where may I find the documentation pages on how
> to scale the values manually?
It's given implicitly in the description of `x_scale'; you have to do
FT_MulFix(face->root.ascender, size_metrics->y_scale);
I've just added this example to the documentation.
|
Wed 12 Jul 2017 08:50:19 AM UTC, comment #2:
Hello Werner,
Thank you for your comments.
I would like to know what I can take from this to fix our regression.
First, regarding the move of the y-scale calculation in 'tt_size_reset', I wonder why it is still considered valid.
We have:
FT_MulFix( face->root.height, size_metrics->y_scale ) );
It is called before the following line:
size_metrics->y_scale = FT_DivFix( size_metrics->y_ppem << 6, face->root.units_per_EM );
For the 'max_advance' calculation, we have the opposite case ('x_scale' gets calculated before 'max_advance').
So, my question is: why are the x and y cases different?
Second, regarding your last comment, where may I find the documentation pages on how to scale the values manually?
Appreciate all the help.
|
Wed 12 Jul 2017 07:09:30 AM UTC, comment #1:
Daniel, thanks for the patches, but both changes were intentional.
As documented, the ascender value gets rounded up. Previously, it was rounded for TrueType fonts and rounded up for everything else, which was inconsistent – in FreeType, global metrics values are computed at font loading time, while hinting gets selected much later (at glyph loading time).
Since metrics rounding was always applied to TrueType fonts before computing the scaling values, linear scaling of metrics was affected in very bad ways, essentially disabling fractional pixel sizes (which do occur if you don't TrueType hinting but light autohinting, say).
If you want `better' global values please scale the values from FT_Face manually (this is also documented, BTW).
|
Tue 11 Jul 2017 07:53:46 PM UTC, original submission:
Hello all,
There seem to be a bit of regression as of v2.8.
Freetype 2 is used for text rendering in the Enlightenment Foundation Libraries (EFL) project.
I attached screenshots that depict the regression I experience.
The left screenshot is of version up to 2.7.2, while the right is of version 2.8.1 and up.
Also, I attached a simple test that verifies the different values produced.
The issue seems to be twofold:
1. In 'tt_size_request', size is not assigned with the new ttsize metrics - this is due to bcc74f4dafee25ea89f1d3144646cba7e30f9908 that seems to intentionally drop this behaviour. I wonder why we are still noticing a regression. One of the attached commits addresses this.
2. The commit bcc74f4dafee25ea89f1d3144646cba7e30f9908 has moved around a few calculations, one of which is y_scale calculation that was moved below the calculation of ascent, descent and height that require this value. The other attached commit addresses this.
Please refer to the simple test program that prints the ascent value of a font.
My output is: 576 (pre-v2.8) vs 640 (post-v2.8).
Thank you,
--
Danny Hirt
|