<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="blue" vlink="purple"> <div class="WordSection1"> 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.<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> Re bugs: I was not suggesting it is a bug, more just asking for any insight into whether there are limitations on scaling accuracy.<o:p></o:p> <o:p> </o:p> I'll try to dummy up a PDF manually to reproduce the issue tomorrow. Thanks for responding.<o:p></o:p> <o:p> </o:p> Linwood<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> From: William Bader [mailto:williambader@hotmail.com] Sent: Tuesday, March 21, 2017 11:11 PM To: pqt@LEFerguson.com; poppler@lists.freedesktop.org Subject: Re: [poppler] Scaling factor and placement accuracy<o:p></o:p> </div> </div> <o:p> </o:p> <div id="divtagdefaultwrapper"> Could you post a PDF example? Poppler issues can be reported at <a href="https://bugs.freedesktop.org/enter_bug.cgi?product=poppler" id="LPlnk359916">https://bugs.freedesktop.org/enter_bug.cgi?product=poppler</a><o:p></o:p> Are you rendering to the screen or to a file? pdftocairo and pdftoppm both have antialiasing options.<o:p></o:p> 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.<o:p></o:p> Regards, William<o:p></o:p> <div> <div> <div class="MsoNormal" align="center" style="text-align:center"> <hr size="2" width="98%" align="center"> </div> <div id="x_divRplyFwdMsg"> From: poppler <<a href="mailto:poppler-bounces@lists.freedesktop.org">poppler-bounces@lists.freedesktop.org</a>> on behalf of <a href="mailto:pqt@LEFerguson.com">pqt@LEFerguson.com</a> <<a href="mailto:pqt@LEFerguson.com">pqt@LEFerguson.com</a>> Sent: Tuesday, March 21, 2017 2:06 PM To: <a href="mailto:poppler@lists.freedesktop.org">poppler@lists.freedesktop.org</a> Subject: [poppler] Scaling factor and placement accuracy <o:p></o:p> <div> <o:p></o:p> </div> </div> </div> <div> 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<o:p></o:p> </div> </div> </div> </div> </body> </html>