Font stroke style misplaced on pdf exports for some heights

[gillnrb]

Hello, this happens in my installation (new 9.1/Win7) to styled texts with certain heigths only
style example is:

font size 3.5 is ok, as is 2.8
font sizes 3.4 and 2.9 misalign the stroke.

Never occurred in previous release

Sample Style:
  .specialCharX {stroke:red; stroke-width:0.1; stroke-linejoin:miter; stroke-linecap:butt; fill:black; font-family:'GPS Sans'; font-size:3.5px;}
  .specialCharY {stroke:red; stroke-width:0.1; stroke-linejoin:miter; stroke-linecap:butt; fill:black; font-family:'GPS Sans'; font-size:3.4px;}

And the Text:
  <text id='DIM_KleinA' x='105.5' y='108' text-anchor='start' class='specialCharX'> ABC123 </text>
  <text id='DIM_KleinA' x='105.5' y='104' text-anchor='start' class='specialCharY'> ABC123 </text>

PDF output is in the attachment

----------------------

Added some more information - in the comments below.
Sorry, first time using this tool, so I messed it up a bit with comments

----------------------

Attached is a testcase and pdf's from 0.48 (good) and 0.91 (bad)
I converted them from command line.
"C:\..\inkscape.exe" -f D:\drawingstemp\....svg -D -A C:\....pdf

The version of pdf output (1.4 or 1.5) switched with commandline-switch in 0.91 gives the same bad results.
I used inkscape-0.91.msi installer.
The font family has no influence. All fonts (ttf) give same results.
A Test with Batik 1.5 rendering to pdf is OK.

It seems to me, that there is some inaccuracy in some sort of division somewhere?
The distance of stroke and char changes with size around a small amount, regardless of size, transformation ...

Feel free to ask for further information.

[gillnrb (gillnrb)]

Please see also https://bugs.launchpad.net/inkscape/+bug/940158?comments=all

[su_v (suv-lp)]

Please add information to the bug description about which installer from inkscape.org was used for Inkscape 0.91:
arch (32bit|64bit), format (msi|exe|paf.exe|7z)

Please also attach a full test case - original Inkscape SVG, exported PDF file (a JPEG raster graphics image (presumably a screenshot) does not allow to further investigate the reported issue under the same conditions on other systems).

It would be of great help if you could include more specific information about the fonts used (including available download links if the fonts have a free and open license).

[gillnrb (gillnrb)]

Hello,
thanks for the very fast Feedback!

Attached is a testcase and pdf's from 0.48 (good) and 0.91 (bad)
I converted them from command line.
"C:\..\inkscape.exe" -f D:\drawingstemp\....svg -D -A C:\....pdf

The version of pdf output (1.4 or 1.5) switched with commandline-switch in 0.91 gives the same bad results.
I used inkscape-0.91.msi installer.
The font family has no influence. All fonts (ttf) give same results.
A Test with Batik 1.5 rendering to pdf is OK.

It seems to me, that there is some inaccuracy in some sort of division somewhere?
The distance of stroke and char changes with size around a small amount, regardless of size, transformation ...

Feel free to ask for further information.

[gillnrb (gillnrb)]

This is the pdf from testcase with 0.91
You can see it, when zooming in

[gillnrb (gillnrb)]

This is the same testcase with 0.48
It is ok.

[gillnrb (gillnrb)]

TTF fonts use only integer for coordinates. Maybe some calculations are less precise now?

[su_v (suv-lp)]

Difference as claimed between Inkscape 0.48 and 0.91 not reproduced on OS X 10.7.5:
The outlining of the stroked characters is rendered "badly" (not precisely fitting the (filled) characters at certain smaller sizes) in PDFs generated using Inkscape 0.48.2, 0.48.5, 0.91 and 0.91+devel, and it also occurs with various tested cairo versions (1.12.2, 1.12.16, 1.14.2). PDF content was "verified/inspected" with Apple's Preview.app and with poppler-glib-demo (PDF tool from latest poppler 0.32).

The difference as reported and demonstrated in the attached PDF files could be related to:
a) the versions of the dependencies bundled with Inkscape (e.g. the 32bit packages of Inkscape ship with outdated unstable cairo snapshot 1.11.2, the 64bit builds of Inkscape 0.91 include cairo 1.14.x (snapshot from rather recent git master).
or possibly to:
b) the circumstance that Inkscape 0.91 on Windows switched the pango font backend from native to fontconfig (same as used on the other platforms).

[ Initially I thought it could be related to the new CFF hinter in recent freetype (see bug #1396582), but the imprecise outlines of the stroked texts at certain (smaller) sizes happens with older freetype versions as well as with latest freetype if compiled to use the old CFF hinter. ]

Another odd fact: conversion of affected PDFs to SVG using poppler (either the new (0.91) option in Inkscape's PDF import dialog; or the command line tool from poppler (pdftocairo)) produces results where the outlined glyphs (from the original filled text) and the outlines from the stroke fit precisely, for all sizes.

[Nathan Lee (nathan.lee)]

Coming back to this issue... 5 years later: do you still replicate this issue in 0.92.5 or later?

For me,

With Liberation Mono installed:
- Replicated 0.91.1 Windows 7
- Not replicated 0.92.4, 1.0.1 Windows 7
- Not replicated 0.92.5, 1.0beta2 (2b71d25, 2019-12-03) appimage, 1.0.1 (3bc2e81, 2020-09-07) appimage, Inkscape 1.1-dev (bee5132fad, 2020-10-20) Linux Mint 20

Without Liberation Mono installed
- Replicated 0.91.1, 0.92.4, 1.0.1 Windows 7 (Courier New is the font fallback used)

So the issue seems to still exist (and can/should be migrated to Inkscape's new bugtracker on GitLab per https://alpha.inkscape.org/bug-migration/), but may be more limited. I did test with a couple other fonts too, but didn't replicate. Tests are not as thorough as above.