Chart test failures on mac: text size differences

[Khaled Hosny]

On Mon, Mar 06, 2017 at 07:56:40PM +0200, Khaled Hosny wrote:
> On Mon, Mar 06, 2017 at 11:21:25AM +0000, Tamas Zolnai wrote:
> > On Tuesday, February 28, 2017 23:42 GMT, Khaled Hosny <khaledhosny at eglug.org> wrote:
> > 
> > > On Tue, Feb 28, 2017 at 11:02:30PM +0000, Tamas Zolnai wrote:
> > > > Hi Khaled,
> > > >
> > > > > I don’t think text width or height are that interesting, but they are
> > > > > probably a good approximation, so I repurposed one of the existing VCL
> > > > > tests to test this[1]. I tried testing also the text bounding rectangle
> > > > > but it showed a 1 pixel difference on Mac, this should be fixed in [2].
> > > > >
> > > > > Feel free to add more test cases that you think are worth having.
> > > >
> > > > I noticed today that some of the Windows tinderboxes fails on the new
> > > > vcl test randomly. They fail on the text width check.  This can
> > > > explain why chart test were failing on the same Windows tinderboxes.
> > > >
> > > > http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER&brief-log=1488318182.31559
> > > > http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER&brief-log=1488315724.23850
> > >
> > > That is weird! Any chance that these machines has a copy of DejaVu Sans
> > > installed system wide that we might be picking instead of the bundled
> > > one?
> > >
> > > This change[1] might help showing the source of the difference that is
> > > causing the failures.
> > 
> > Hi Khaled,
> > 
> > Did you see the current build failures?
> > Here are two failures:
> > http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER&brief-log=1488779385.27281
> > http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER&brief-log=1488782916.5676
> >
> > Interestingly it's the same tinderbox which is sometimes happy with
> > the test, sometimes fails with 75 and sometimes fails with 91 as text
> > width.
> > Clearly we have some wierd behavior here.
> 
> 
> Unfortunately we still don’t get much information to debug this,
> hopefully [1] will help a bit e.g. to see if there are accumulating
> small differences in character widths which would suggest rounding
> issues, or completely different ones which would suggest a different
> font. Unfortunately OutputDevice has no public API to tell which font it
> ended up using.

So we have now a bit more clue:
http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER&brief-log=1488908931.16918#err2
http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER&brief-log=1488900164.7942#err2

In the first one the numbers are so completely different that I’m fairly
positive that we are getting a different font than we requested (DejaVu
Sans Book), in the second one is not so obvious but the differences do
not look like accumulating rounding errors either (since these so called
“character widths” are cumulative, i.e. from the start of the text to
the end of current glyphs, a rounding error would increase all
subsequent widths) so I think this is likely a different font as well.

I have no idea how to debug this, though without being able do reproduce
this locally. Make be we can added some API to OutputDevice to tell us
what the font is actually using, but even then I’d still not know why we
are not getting the font we requested given that it is a bundled font.

Regards,
Khaled