I am attaching an example. I tried to get it to just one note without success, it appears to matter where these appear on the page horizontally not just vertically, so I just experimented with a very few notes until I got a size that worked. The issue is in the third measure on the bottom staff and the second note. That note should be bisected by the line, instead it is significantly too high, ambiguous with being between lines (i.e. it is an F, it looks like a G if you read music).
The JPG shows how I see it. Viewed in Adobe it is correct. The relevant code that produces it is this: Poppler::Page* tmpPage = ((PDFDocument*)ourParent)->document->page(mPage - 1); QSizeF thisPageSize = tmpPage->pageSizeF(); // in 72's of inch double scaleX = (double)mWidth / ((double)thisPageSize.width() / (double)72.0); double scaleY = (double)mHeight / ((double)thisPageSize.height() / (double)72.0); double desiredScale = std::min(scaleX, scaleY); ourParent->document->setRenderHint(Poppler::Document::Antialiasing); ourParent->document->setRenderHint(Poppler::Document::TextAntialiasing); ourParent->document->setRenderHint(Poppler::Document::ThinLineSolid); QImage* theImage = new QImage(tmpPage->renderToImage(desiredScale,desiredScale)); The variables are: mPage = 1 thisPageSize = (612,792) mWidth=1200 mHeight=1857 desiredScale = 141.176 (as printed if I add qDebug()). The extraneous "double" casts were just making sure I was keeping double precision, as the printed value of 141.176 (when I write to qDebug()) on the scale looks a bit odd, as the math works out to 141.1764706... I did a lot of photoshop exploring and I am pretty sure this is a matter of a single pixel. That was a surprise, that you can even see that (this is normally on a 1920x1080 screen). So this may actually just be a rounding issue (if "issue" is not too strong of a word). I'll dig a bit in the code, but am handicapped by not knowing a thing about the actual PDF structure, so the code is a bit mysterious in terms of where the object placement may be, at least at present. But I'll give it a shot, meanwhile will truncate to an integral scale factor and see if I see the issue as we use the software. Again, I realize it's a pretty picky detail, especially as I am seeing it may be literally one pixel difference, so thanks in advance to anyone willing to follow all this and make suggestions. Linwood Ferguson From: poppler [mailto:[email protected]] On Behalf Of [email protected] Sent: Tuesday, March 21, 2017 11:23 PM To: William Bader <[email protected]>; [email protected] Subject: Re: [poppler] Scaling factor and placement accuracy I'm working with music that is copyrighted (that I own) that I digitize and the produce the PDF's from the digitization (for my own use). Let me see if I can find one that's public domain and reproduce the issue there. Or maybe better yet just dummy something up manually. I don't want to get the copyright swat team interested. I am rendering to an image in a QT5 program via the QT5 wrappers for poppler, then displaying the image on the monitor. My initial runs were with PDF's containing just one big image, but when I put the music into notation software (Musescore in this example) the resulting PDF, I believe, has individual objects for each element on the screen. Though that's more educated guess than sure fact. I did some brief experimenting forcing the scale to integers, and did not see the problem, but it was way too brief; by complete coincidence my piano's player system was being replaced today so I did not have opportunity to experiment very much. Re bugs: I was not suggesting it is a bug, more just asking for any insight into whether there are limitations on scaling accuracy. I'll try to dummy up a PDF manually to reproduce the issue tomorrow. Thanks for responding. Linwood From: William Bader [mailto:[email protected]] Sent: Tuesday, March 21, 2017 11:11 PM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [poppler] Scaling factor and placement accuracy Could you post a PDF example? Poppler issues can be reported at https://bugs.freedesktop.org/enter_bug.cgi?product=poppler Are you rendering to the screen or to a file? pdftocairo and pdftoppm both have antialiasing options. I think that Splash filling is done in poppler/SplashOutputDev.cc and Gfx.cc. The type of fill depends on the commands in the PDF, so probably the first step would be looking at the PDF to see how it draws the notes. Hopefully one of the poppler developers will have more detailed advice. Regards, William ________________________________ From: poppler <[email protected]<mailto:[email protected]>> on behalf of [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Tuesday, March 21, 2017 2:06 PM To: [email protected]<mailto:[email protected]> Subject: [poppler] Scaling factor and placement accuracy OK, this is going to seem awfully picky, so with apologies in advance. Can anyone offer some guidance as to whether scale factors, when doing a renderToImage, have an internal effect on accuracy? I have been chasing a very minor, but very annoying issue, and I think it comes down to what scale factor is in use. The application I wrote dynamically scales the PDF page image to the nearest size it can to completely fill the page while maintaining aspect ratio. This displays music. The music is sometimes (specifically when coming from notation software) individual items, where each note is a PDF element. In those cases, sometimes, not often but sometimes the notes are misplaced a bit. I am attaching an example. I actually have seen much worse, but I had this handy with all the debugging. On the bottom example it is a screen shot of Adobe's reader. The top is Poppler's rendering at scale 150. The middle is the problem example, it is scaled 98.1818 (I have rescaled the screen shots to be the same size in photoshop to produce the collage for viewing). Notice the ever so slightly higher position of the F's (second from top note) on the middle staff. I've tried to indicate the center with the hand-drawn arrow. That may seem like a slight issue, but these are occurring quite a lot, and they fool the eye when sight reading causing you to think it is the wrong note. Originally I thought it was the notational software, but Adobe's viewer, and even Poppler at some scaling factors places them perfectly. At others they are shifted. I plan to now do some experimentation with different roundings, and try to see a pattern, but for people who know the code ... is there any guidance? Like use integers, or some other limitations on scale factors? Or perhaps are there any compilation options that impact the accuracy of the calculations? This is the latest committed version of poppler pulled and built from source today with the default rendering engine (Splash) and with hints Antialiasing, TextAntialiasing, and ThinLineSolid turned on . The problems have been on the Raspberry pi, so it's 32 bit os, but both the top and middle example in the attachment are on the Pi, so it is not always an issue. Anyway, again apologies if this seems like an awfully trivial item, but was just hoping someone may have encountered similar issues and had any advice. Linwood Ferguson
test - Unknown.pdf
Description: test - Unknown.pdf
_______________________________________________ poppler mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/poppler
