2

The application is a map onto which GeoJSON files (among other formats) can be dropped and viewed.

Recently we added a feature to print the current map view to PDF. The two parameters I need to test are size (A4, A3 etc) and DPI (which is fixed at 300DPI).

It’s easy to design a test for the first parameter but I am not so sure about the second (DPI). My strategy is so far:

  1. Drag two GeoJSONs onto the map, ((!): GeoJSONs contain vector graphics)
    a. each coloured differently (eg. one red, one blue) and
    b. each with 300 equally-spaced parallel lines
    c. displace one file by half the spacing so that the two sets of lines are interlocking, like a zipper.

  2. Set zoom level accordingly, to measure one Inch across the stack of parallel lines (that’s logical, because I want 300 lines per inch)

  3. Export the PDF.

At this point I’m not sure what the result should be. I see a block, that’s for sure. But what colour will it be?! Colour of either GeoJSON or a mix? (Eg. red OR blue for the whole block, or purple)?

And the key question... is this a valid test for proving 300DPI?

bumped to the homepage by Community 6 hours ago

This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.

  • 2
    What language are you using for testing? Basically, you could read the PDF with a corresponding library, extract all images, and then check the DPI for each image. – beatngu13 Feb 16 at 14:24
  • At this stage I am only interested in the principle, writing the manual test-case if you will. Not yet looking at test-automation :) – Stuart Feb 18 at 10:16
  • 2
    But it's not automation that's the issue here, it's validation. Are you actually going to count all 300 lines, and verify that they're equidistant apart? – Kevin McKenzie Feb 18 at 18:50
  • @KevinMcKenzie neither I nor the customer will count 300 lines!! I guess that’s kind of the whole point of this exercise, validating whether seeing a purple block consisting of red and blue lines is proof that the PDF was printed at 300DPI. – Stuart Feb 18 at 19:09
  • 2
    Right, and that's the point. Unless you or the customer count all the lines, you aren't validating that the PDF was printed at 300 DPI. @beatgnu13's approach is a much better one. – Kevin McKenzie Feb 18 at 19:14
0

I think I figured it out (still please correct me if I'm wrong). I was almost right with my original approach. My mistake was very basic and (dare I say it) stupid.

I have been trying to squeeze 600 lines in one inch: 300 blue lines, 300 red lines. What I should have done is halve the amount of lines per colour: 150 blue lines, 150 red lines to give me 300 parallel lines in one inch.

Now when I export the PDF, I get a purple(ish)-looking block when zoomed at 100%. If I zoom into the PDF, I am able to see the individual red and blue lines stacked on top of each other.

I take it the purple colour when zoomed at 100% does not look uniform on my machine because of my crappy integrated graphics?

Various screenshots

  • I see the same banding and the like, but I'm not sure this is a good way of testing things, as you're putting a lot of code between you and what you care about. – Kevin McKenzie Feb 18 at 18:49
  • Can you elaborate on “lot of code between you and what you care about”? – Stuart Feb 18 at 19:02
  • 1
    Yes. As you say, you see banding on the image; I see it as well. I'm not running on an integrated GPU. So whatever's causing it isn't that. Does the banding matter? Quite possibly, but based on the question, you're trying to validate that a PDF will be generated at 300 DPI. So the thing you really want to know is what is the DPI of the PDF. Your approach, of creating an overlay and then loading the PDF into some sort of viewer (Adobe, probably, but could be FoxPDF or something else) means that you're using that program to validate the correctness of your program. It's entirely ... – Kevin McKenzie Feb 18 at 19:06
  • possible that the banding is due to either the viewer program, or due to something about the way the overlay was generated. In this case, what you say you care about is that the PDF is generated at 300 DPI, so a much better way of validating that would be to interrogate the generated file directly. Potentially you could use something like pdfimages, which will tell you the DPI of the image, or you could use Adobe Acrobat Pro, which will apparently do so as well. And in both these cases, you again have code between you and the PDF, but you're actually measuring the thing you care about. – Kevin McKenzie Feb 18 at 19:12
  • Thanks clarifying but I still disagree that using another tool to spit out a DPI is the way to go. That means I would have a whole other application between me and what I care about, trusting the value without knowing that it is really correct. With my method, I am able to see the result with my own eyes, in the same PDF viewer the customer will be using. Additionally, since my last post we did some tweaks and improved the quality of the image (the browser was converting the image to jpeg before, now it is png). – Stuart Feb 19 at 11:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.