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 _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest