Dmitry Shachnev dixit:
>Will you be able to forward your patch upstream when you finalize it?
Sort of. I can do the CLA, Gerrit, etc. dance, but I probably cannot
respond well if they want me to test things with vanilla upstream
(instead of the packaging), or if they have requests I as a C (but
not C++) developer don’t understand.
(The other half of fixing things is even more challenging. I got a
confirmation that Mu͒seScore Evolution upstream cannot upgrade their
Qt versions so they’ll need a different fix subclassing and overriding
the library functions for some cases. If anyone sufficiently proficient
in C++ is interested in helping with that, once we got the fix for Qt
itself going, ping me. Alternatively, helping to figure out how to patch
and rebuild the exact versions they use for Win/Mac or upgrade their
versions without losing Win7 and qtwebengine, IIUC — AIUI their Mac OSX
builds are still at Qt 5.9 for that reason…)
>> +static inline int roundForBbox(qreal v)
>> +{
>> + return (v < 0) ? floor(v) : ceil(v);
>> +}
>
>I see you are passing negated values to this function, e.g. roundForBbox(-x).
Not only them. And roundForBbox is basically just the canonical
“round away from zero / towards ±infinity for integer results”.
The negation in the callers is to convert *some* Qt coordinates
to PS/PDF coordinates, but only for the Y axis, as the X axis is
the same for them.
>I see why you moved properties to the top, but is moving postscriptName
>needed? Maybe leave it where it was to minimize the diff?
It’s not. I moved the whole block to make it easier to read,
but good point.
>You are passing scalep pointer here only to multiply it by this value?
Yes.
>It looks like fontEngine is a public member of QFontSubset, so you can
>do it in the calling code.
Yes, except it’s the callee that determines the scaling factor,
not the caller. By passing it back like this, nothing would have
to change in the caller should the callee ever decide to not scale.
Sune Stolborg Vuorela dixit:
>I can't find any references to something that look like a "OS/2" table
>in the pdf spec.
That’s because we’re talking about OTF/TTF-format tables here.
The problem exists at two different layers.
One is that, when embedding and subsetting a font, Qt generates
a PDF font descriptor whose bounding box is wrong.
The other is that, when embedding and subsetting a font, Qt
converts it to quadratic-spline TTF and scales it to 2048 ppem,
then embedding the resulting TTF in the data object corresponding
to the above-mentioned font descriptor (the data object itself,
when extracted, is a fully functional .ttf font file). The OTF/TTF
file format has description tables, and Qt does not correctly adjust
all values in all tables it includes when scaling the font itself.
>Just to help me double check, how is is the OS/2 table described in the
>font in the pdf ?
The references I’ve been using are:
PDF:
https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/pdfreference1.0.pdf
TTF: https://learn.microsoft.com/en-us/typography/opentype/spec/
The OS/2 table specifically is documented at:
https://learn.microsoft.com/en-us/typography/opentype/spec/os2
bye,
//mirabilos
--
18:47⎜<mirabilos:#!/bin/mksh> well channels… you see, I see everything in the
same window anyway 18:48⎜<xpt:#!/bin/mksh> i know, you have some kind of
telnet with automatic pong 18:48⎜<mirabilos:#!/bin/mksh> haha, yes :D
18:49⎜<mirabilos:#!/bin/mksh> though that's more tinyirc – sirc is more comfy
