Created attachment 138147 [details] [review] WIP patch that implements ArthurOutputDev::drawImageMask I am trying to implement type3 font support for the Arthur backend. When such fonts are present, the method ArthurOutputDev::drawImageMask is called repeatedly, which is currently empty. So I figured I'd go and implement that method first. Attached is a prototype implementation that I hacked together using the information from http://www.verypdf.com/document/pdf-format-reference/pg_0350.htm My problem now is that I do not have an example file to test this. All the files I have call drawImageMask as part of type3 font rendering, which adds an additional layer of mystery to the problem. Can anybody help me out with a pdf file that contains an image mask but no type3 fonts?
Created attachment 138381 [details] [review] Patch that implements ArthurOutputDev::drawImageMask
I updated the patch: the old patch had the meaning of the 'invert' flag inverted (sic). By now I have a working protoype for type3 font rendering that uses drawImageMask, so my drawImageMask implementation can't be all that bad. Please test and review! Thanks.
Created attachment 138382 [details] [review] Document the method 'OutputDev::drawImageMask' Here is a bit of documentation for the OutputDev::drawImageMask method.
Hmmmm, can you have a look at the 090_Font-Support_x3.pdf file i'm attaching? With your patch there's a big n appearing on the bottom left that seems like shouldn't be there?
Created attachment 138385 [details] said file
That big 'n' is one of the type3 font letters contained in the file. I think what is happening is the following: - ArthurOutputDev claims to do type3 support by the beginType3Char/endType3Char mechanism - Hence beginType3Char/endType3Char are being called, but they do nothing. - In between, the actual glyph rendering operations are called. For each glyph there is one call to drawImageMask, because the font is a bitmap font. - But since beginType3Char/endType3Char do not do the necessary transformations, the glyph rendering identifies font coordinates and page coordinates, and all letters appear in the lower left corner. The one you see is the last one. My explanation is substantiated by the following simple patch, which switches off type3 rendering for good. Then the 'n' is gone (but also drawImageMask is not called anymore, and the document ceases to be a good test case for that method). Thinking about this some more, one could probably implement type3 font support by "simply" making beginType3Char/endType3Char do the correct transformations. This would be an alternative implementation to https://bugs.freedesktop.org/show_bug.cgi?id=105772 and possibly simpler. Given that 105772 already kind-of works, do you think the alternative should be explored?
Created attachment 138640 [details] [review] Patch that really switches of type3 font rendering
I guess that if at this stage the type3 fonts don't work the best is simply switch them off. Do you want me to start a regtest with the patch that disables them?
Yes, please! BTW, do the other glyphs in the example document look good for you? Because on my machine some of the fonts are way too heavy. Unfortunately, my impression is that the problem appeared after some random Debian testing update, and it may be a Qt bug.
I've pushed it, to be honest i only went through like 50 of the 300 files the regression test found differences on, but the 50 first files were a definitive improvement so let's say this is a step in the right direction :)
Thanks! Would you also push the documentation patch? BTW, should such patches use doxygen syntax or something similar?
Are you sure the documentation is totally correct? I'm not saying it isn't. i'm not very well versed on what the method exactly does. I'm just saying that sometimes is preferable to have no docu than docu that is partially wrong, but if you're totally sure it's correct i'll push it :)
Yes, I am totally sure.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.