After hacking scale factor of 1000 out, the first few pages of glpyhs are
identical, but toggling glyphs in the higher up (gid 300-470) at 72em, they
don't quite line up - horizontally moved. It seems to have color glyphs to
about 470, after that 470 to 1138 are just b/w.
On Tuesday, 23 May 2023 at 23:40:29 GMT+8, Hin-Tak Leung
<[email protected]> wrote:
On Tuesday, 23 May 2023, 05:25:27 BST, Werner LEMBERG <[email protected]> wrote:
> Please give more details, using valgrind options `--leak-check=full`
> and `--show-leak-kinds=all` together with setting environment variable
> `FT2_DEBUG=any:7`.
Actually FT2_DEBUG=any:7 was enough to see what the problem is. The svg code
path is trying to do bitmaps
1000x1000 bigger than the glyf code path (compare the same glyph - I only get
only about 7 glyphs for 400 ppem).
If I insert into src/rsvg-port.c , around line 255, something like the below, I
can toggle between b/w and more or less correctly:
=======================
/* Scale factors from SVG coordinates to the needed output size. */
x_svg_to_out = (double)metrics.x_ppem / dimension_svg.width;
y_svg_to_out = (double)metrics.y_ppem / dimension_svg.height;
+ if (((int)out_width.length == 1) && ((int)out_height.length == 1)) {
+ x_svg_to_out /= units_per_EM;
+ y_svg_to_out /= units_per_EM;
+ }
+
/*
* Create a cairo recording surface. This is done for two reasons.
* Firstly, it is required to get the bounding box of the final drawing
========================
I think I remember seeing somewhere that a width and height =1 is special, in
the opentype spec? what width and height do you get in this location?
Hin-Tak
