On 24.10.2015 11:13, Werner LEMBERG wrote:
Looking at EBLC data, there's only one strike available, metrics are:
---
Horizontal Line Metrics
Ascender: 8
Descender: 8
This is a bug in the font, making the strike's glyph height
effectively zero (or not, see below).
What freetype does in tt_face_load_strike_metrics():
---
metrics->ascender = (FT_Char)strike[16] * 64; /* hori.ascender */
metrics->descender = (FT_Char)strike[17] * 64; /* hori.descender */
metrics->height = metrics->ascender - metrics->descender;
---
The question is mostly if it's reasonable to have some kind of
workaround for that in freetype itself, like ignoring descender
entirely in such cases or something else?
This is a good question. First of all, there is a problem with the
specification. It doesn't tell us whether positive or negative
`descender' values in the `sbitLineMetrics' record indicate ink below
the baseline. Looking into the corresponding Apple specification for
the `bloc' table, I see similar fuzzy wording.
Right, I tried to look it up before sending initial request, and nothing
solid came up.
I've now taken a look into some EBLC tables of (older) fonts
distributed by Microsoft (Windows 7), and even here I find strikes
with invalid ascender and descender values all set to zero
(`calibri.ttf' version 5.62), fonts where we have positive descender
values (`cour.ttf', version 5.11), and fonts where we have negative
values (`simsun.ttf', version 5.03). In other words, it's a complete
mess, and I came to the conclusion that we must not trust those
values.
In the git repository you can now find some heuristics to change a
positive bitmap strike descender value to a negative one (this fails
for your Misaki version since the values are too broken), and to get a
non-zero height (which always works). Please test.
Thank you for a quick fix. I just tested it, and with enabled tracing I
can see this new code is used, and fixed up height is there. But there's
one issue that zeroes height anyway by the time it gets back to me. I'm
using 'available_sizes' to access that, and it seems the problem is that
new fixed up metrics are not using 26.6 format - see attached patch.
With this fixed I don't get 0 height anymore. Thanks again.
Nikolay
Werner
From 60219890f635e4671e94cf50e935f0383ecfd4e2 Mon Sep 17 00:00:00 2001
From: Nikolay Sivov <[email protected]>
Date: Sat, 24 Oct 2015 16:11:52 +0300
Subject: [PATCH] [sfnt] Fix bitmap strike metrics scaling
---
src/sfnt/ttsbit.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/sfnt/ttsbit.c b/src/sfnt/ttsbit.c
index 4272d93..a862456 100644
--- a/src/sfnt/ttsbit.c
+++ b/src/sfnt/ttsbit.c
@@ -289,12 +289,12 @@
/* sanitize buggy ascender and descender values */
if ( max_before_bl || min_after_bl )
{
- metrics->ascender = max_before_bl;
- metrics->descender = min_after_bl;
+ metrics->ascender = max_before_bl * 64;
+ metrics->descender = min_after_bl * 64;
}
else
{
- metrics->ascender = metrics->y_ppem;
+ metrics->ascender = metrics->y_ppem * 64;
metrics->descender = 0;
}
}
@@ -313,7 +313,7 @@
" "
" for strike (%d, %d)\n",
metrics->x_ppem, metrics->y_ppem ));
- metrics->height = metrics->y_ppem;
+ metrics->height = metrics->y_ppem * 64;
}
/* Is this correct? */
--
2.6.1
_______________________________________________
Freetype mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype
