Line-height and text size difference 0.91 vs. 0.92.1pre2

[Hachmann]

Not sure if this is not supposed to be fixed (but from the commit messages I thought it was), so please close if this is to be considered a duplicate of some other bug.

With the attached file, I still get a different output for my text in 0.91 and 0.92.1pre2.

Some text is missing, some has the lines all above one another, and some has a different font size (apparently) and runs out of the drawing borders.

The text that was previously broken is fine now, though... :-( But other text is broken.

[su_v (suv-lp)]

Attaching command line PNG exports done with Inkscape 0.91 and 0.92.1pre2 (on OS X 10.7.5) of the drawing area (both with 90dpi) to the report - AFAICT there are neither "lines all above one another" nor text with largely differing font sizes; I do see one last line of a flowed text being truncated (probably due to the minimal vertical offset which cannot be corrected), and one other line with larger differences than expected.

The output of perceptualdiff between the two files:
 922 pixels are different
(the output image is included in the ZIP archive)

Could you attach a version of the SVG file resaved under a different name after opening it in Inkscape 0.92.1pre2 on your system (with no changes applied otherwise)?

The file is rather large - you don't happen to have a list at hand of the exact fonts used in he texts? Possibly the reported issue is related to certain fonts I don't have installed locally yet.

[su_v (suv-lp)]

Used fonts via Extensions > Text > Replace Fonts > List all fonts:

'FreeSans Italic'
'FreeSans Semi-Bold Italic'
'FreeSans Semi-Bold'
'FreeSans, Italic'
'FreeSans, Semi-Bold'

Locally installed: freefont-ttf-20120503.zip

'Liberation Sans Bold Italic'
'Liberation Sans Bold'
'Liberation Sans'

Locally installed: liberation-fonts-ttf-2.00.1.tar.gz

'Patrick Hand'
'Patrick Hand, Normal'

Seems on hidden layer, not relevant (available via Google Fonts).

[Hachmann (marenhachmann)]

Mmh, yes, that diff of yours is tiny. I get a totally different result, so I'm really wondering what I might be doing wrong.
Can't be a different pango version or something?

Find the requested save from 0.92.1pre2, and two exported pngs (drawing area, objects selected so those that run out of the image won't disturb diff creation, i.e. scale should be same, and those objects are cut off on the borders) in the attachment.

Font is just FreeSans, and nothing else, as comes with Ubuntu 16.04 / Linux Mint 18.1.

I'm having two Inkscapes installed and running, both using separate preferences files, thanks to having found out that there's an environment variable that can be set. The one for the 0.92.1pre2 version originates from some 0.92 version along the way, so it's 'new'.
I have used Bryce's tar file from the website for compiling, and have verified that it contains the latest changes (checked with the changes from Jabier).

[su_v (suv-lp)]

I used local a build of lp:inkscape/0.92.x r15365, GTK+/X11 backend for testing (cli, GUI), no relevant local changes in that branch (except for keeping build date in version string).

Now compiling from 0.92.1pre2 tarball (downloaded from launchpad.net); after that testing the same file with lp:inkscape/0.92.x r14365 on Ubuntu 14.04.5 LTS.

[su_v (suv-lp)]

Not reproduced with clean build from tarball (inkscape-0.92.1pre2.tar.bz2) on OS X 10.7.5.

Not reproduced with lp:inkscape/0.92.x r15365 on Ubuntu 14.04.5 LTS.
Installed FreeSans font is from Ubuntu packages [1]
The local changes in the build are
- diff for bug #1661771 (does not affect this file)
- latest diff for bug #1659229 (does not affect this file)
- diff for bug #1662439 (does not affect baseline spacing fix)

--
[1] http://packages.ubuntu.com/trusty/fonts-freefont-ttf

[su_v (suv-lp)]

Reproduced on OS X 10.7.5 with both mentioned builds (stable branch, pre2 tarball) if launching inkscape with locale de_DE:

$ LANG=de_DE.UTF-8 inkscape Programm_Flyer_Entwurf_2016.svg

[Hachmann (marenhachmann)]

Weird. Thank you for testing, su_v. Do you have any idea what could be causing this difference?
(I could upload my deb package, or zipped build directory, if that helps...)

[Hachmann (marenhachmann)]

Btw. it looks the same for me (broken, as in screenshot from 0.92.1pre2) when I open the saved file with 0.91 again.

[Hachmann (marenhachmann)]

replace 'screenshot' with 'png export', sorry for the noise.

[Hachmann (marenhachmann)]

Composed comment #8 before I read #7, thank you! (I'm somehow glad that it's not some oversight by myself... although, from the program fixing side, I'd have preferred that.)

[su_v (suv-lp)]

Testing with (random) other locale via cli:
- ok: en_US, en_GB, ja_JP, zh_TW, zh_CN, he_IL, C
- not ok: fr_FR, it_IT, es_ES, ru_RU, pt_BR

Note that the bug does not reproduce if the UI language is selected via Inkscape preferences (while launching inkscape with the default locale as defined for the terminal) - tested with German and French.

@Mc - any idea what could cause this? Symptom is the same independent of whether locale is defined via $LANG or $LC_ALL.

[su_v (suv-lp)]

AFAICT this seems to affect all files - at least for example those in the test repo:
 https://gitlab.com/su-v/test-files/

Unlikely relevant: if the files are opened with the fix disabled:
$ LANG=de_DE.UTF-8 inkscape --no-convert-text-baseline-spacing affected_file.svg
using the extension (inx-legacytext) does not expose the reported issue.

[su_v (suv-lp)]

On Ubuntu 14.04.5 LTS:
$ locale -a
C
C.UTF-8
de_CH.utf8
en_AG
en_AG.utf8
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IN
en_IN.utf8
en_NG
en_NG.utf8
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US.utf8
en_ZA.utf8
en_ZM
en_ZM.utf8
en_ZW.utf8
it_CH.utf8
it_IT.utf8
POSIX
$
$ locale
LANG=en_US.UTF-8
LANGUAGE=en_US
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=de_CH.UTF-8
LC_TIME=de_CH.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=de_CH.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=de_CH.UTF-8
LC_NAME=de_CH.UTF-8
LC_ADDRESS=de_CH.UTF-8
LC_TELEPHONE=de_CH.UTF-8
LC_MEASUREMENT=de_CH.UTF-8
LC_IDENTIFICATION=de_CH.UTF-8
LC_ALL=
$
$ LC_ALL=en_US.utf8 inkscape affected_file.svg # ok
$ LC_ALL=en_GB.utf8 inkscape affected_file.svg # ok
$ LC_ALL=it_CH.utf8 inkscape affected_file.svg # ok
$ LC_ALL=it_IT.utf8 inkscape affected_file.svg # reproduces

Launching with $LANG on Ubuntu seems ok so far (does not reproduce) for any of the 4 tested locales. Launching with $LANGUAGE (e.g. LANGUAGE="de") does not reproduce either (but switches UI language).

[su_v (suv-lp)]

$LC_NUMERIC (decimal separator, '.' vs ',') is possibly the cause?

[Hachmann (marenhachmann)]

<offtopic>
Forgot to say yesterday: su_v, you deserve the golden detective hat - how did you guess that this could be the issue?
</offtopic>

[su_v (suv-lp)]

<off-topic>
On 2017-02-09 14:51 (+0100), Hachmann wrote:
> how did you guess that this could be the issue?

After tests with different builds had been exhausted and without result,
I tried to re-focus on what differences there might be between yours and
the tests run locally (build, runtime). Recalled your screenshots I had
seen posted elsewhere, with German UI. It seemed implausible, but easy
enough to test. I vaguley recalled that this is not the first time that
a specific issue is exposed only with certain locale settings (a quick
search done later e.g. refers to bug #1425317, there are likely others).
</off-topic>

[Hachmann (marenhachmann)]

<off-topic>
"Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth."
</off-topic>

[Hachmann (marenhachmann)]

I don't like to ask this, but:

Would this qualify as a blocker?

A newly introduced function that was supposed to fix the line spacing is breaking it for many languages.

[su_v (suv-lp)]

Mc was working on it late last night: the cause has been identified, an initial patch was shared and discussed on irc, tested on Ubuntu 14.04 and OS X 10.7.5 so far. Expect further updates later today (Friday evening CET).

[su_v (suv-lp)]

Here's a brief summary of the issue:
> Mc : g_strdup_printf respects the locale (contrary to sprintf)
> Mc : and it's used to print the value to the xml code
> Mc : of the code reads the value of 1.25 to set as value
> Mc : translates it to "1,25"
> Mc : then fails to set it
> Mc : patch will be straightforward

The release manager was notified about the regression (that could potentially delay the release) yesterday morning on irc, and the proposed patch has already been accepted (also on irc):

> bryce : Mc, yes that patch fits as minimal, given su_v's testing,
> ack +1 for landing the patch on 0.92.x. (...)

@jazzynico - could you please add a bug task for 0.92.x, and milestone for 0.92.1? The regression affects both lp:inkscape (trunk) and lp:inkscape/0.92.x (stable branch).

[Hachmann (marenhachmann)]

Thank you, su_v, Mc and everyone else involved!

[Mc (mc...)]

Pushed to 0.92.x r15368 and trunk r15503.

[Mc (mc...)]

(NB wrt to comment #21: after checking, "contrary to sprintf" is wrong, sprintf exhibits same behavior)