Databases
StackOverflow2013
Postsdbo
POPython/PDF Creation Using ReportLab - self-made grid prints with a pattern but looks fine on the screen
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POPython/PDF Creation Using ReportLab - self-made grid prints with a pattern but looks fine on the screen
    primarykey
    data
    text
    <p>I am trying to make my own grid (that looks very much like this: <a href="http://tinyurl.com/cdyre6k" rel="nofollow noreferrer">http://tinyurl.com/cdyre6k</a> - ECG paper that is in metric units of millimeters).</p> <p>I am using ReportLab/Python (opensource) to make these reports. Below is a snippet of my code.</p> <p>On the screen, it looks GREAT!: </p> <p><img src="https://i.stack.imgur.com/f0rvb.png" alt="&gt;What I see on the screen&lt;"></p> <p>However, when I send this to a printer (and yes, I've also tinkered with printer settings) it prints some lines, and not others (sometimes it's methodical and prints a pattern-esque plaid, other times it is thicker/thinner lines; keep in mind, the output at the printer is consistent depending on strokewidths I set). </p> <p><img src="https://i.stack.imgur.com/iHp85.png" alt="&gt;What I see at the printer!&lt;"> </p> <p>I have tried all sorts of strokewidth combinations, and all sorts of printer setting combinations... I can't get it to print correctly! I have tried an alternative printer and gotten MUCH better results, but I have to set the printer settings to over 1200 dpi (CAD level printing). The other printer is set to 600dpi. On that SAME PRINTER (600dpi) I print a document made by a former coworker and it print's just fine (please note, he was not using ReportLab so I cannot use his code/solution). </p> <p>What is going on? Is this an aliasing issue at the printer? Would it help me if I coverted my grids to bitmaps (or some other format)? How can I fix this (my only options are to use Python and ReportLab)? ReportLab manual didn't help, "Google" didn't help, and previous StackExchange questions didn't seem to cover this specific topic. I can get the grid to print all the lines if I set the strokewidth to "1", but then the minor grid lines are too thick. </p> <p>The end result is for a line chart I am working on, and I know ReportLab has chart functions, but reportlabs charts/grid function(s) don't give me what I need for my project, so I have been forced to make my own grid with major/minor lines (maybe I missed something and open to alternative techniques, but currently it looks fine in PDF form, just not at the printer). </p> <p>ANY advice is appreciated!</p> <p>TIA, </p> <p>-J</p> <pre><code> for i in decimal_range(0, _time, 1): if (i % 5.0 == 0): if (i % 25.0 == 0): grid_pattern.add(shapes.Line(_temp_x, (_temp_y + _height_of_box), _temp_x, (_temp_y + _height_of_box+4), strokeWidth=1, strokeColor=colors.black)) else: pass grid_pattern.add(shapes.Line(_temp_x, _temp_y, _temp_x, (_temp_y + _height_of_box), strokeWidth=.12, strokeColor=colors.pink)) else: grid_pattern.add(shapes.Line(_temp_x, _temp_y, _temp_x, (_temp_y + _height_of_box), strokeWidth=.12, strokeColor=colors.pink)) _temp_x += 1 * mm _temp_x = xorigin for i in range(0, _mv, 1): if (i % 5.0 == 0): grid_pattern.add(shapes.Line(_temp_x, _temp_y, _temp_x + _width_of_box, _temp_y, strokeWidth=.12, strokeColor=colors.pink)) else: grid_pattern.add(shapes.Line(_temp_x, _temp_y, _temp_x + _width_of_box, _temp_y, strokeWidth=.12, strokeColor=colors.pink)) _temp_y += 1 * mm </code></pre> <p><strong>UPDATE1</strong></p> <p>I have tried setting the stroke width to "0" as recommended by several posters (and the ReportLab community/mailing list) as follows:</p> <pre><code>grid_pattern.add(shapes.Line(_temp_x, _temp_y, _temp_x, (_temp_y + _height_of_box), strokeWidth=0, strokeColor=colors.pink)) </code></pre> <p>This does make a single pixel-wide line, which again, looks great on the PC, but still prints with a funky pattern in PDF.</p> <p><strong>UPDATE2 + SOLUTION</strong></p> <p>After LOTS of tantrums and arguments with ReportLab and my computer it turns out it wasn't my PC or ReportLab. It was the printers (I was using two totally different printers Canon and HP - models notwithstanding) - I felt that I had enough coverage to rule out the printer, but there is more to this problem! Continue reading...</p> <p>ReportLab doesn't actually draw the line, it just adds a postscript line that tells the render to draw the line.</p> <p>Part of my initial debugging included changing the colors I was using to see if that was an issue - well - I changed the colors from pink to red (not much of a change, I know, but again, I <em>assumed</em> I changed it enough to rule out colors as an issue).</p> <p>Well from what I have recently, and painfully learned, is that the printers convert colors to grayscale using a formula and that formula has a tendency to produce antialiasing side-effects (like what I was seeing). </p> <p>THE SOLUTION: was to change the colors of the grid. Certain colors perform better than others. So, to test this, I wrote a simple script which you can <a href="http://www.jrcresearch.net/downloads/printtest.txt" rel="nofollow noreferrer">download here</a> that will generate a PDF document using all of the colors stored in reportlabs colors dictionary - print a sample grid that was causing me the problems and provide the RGB values. As it turns out, alllllllll sorts of colors don't print well across several printers (all different) - it's not just reds/pinks... some "red-like" colors print fine, some printers handle the grayscale conversion better than another. </p> <p>So now, our task is to use this PDF document I created to find a color that looks fine in print (both color and grayscale) and on the screen. </p> <p>If you don't want to download the script for fear I'm evil - at least check out the PDF and print your own samples to see if you can recreate the problem I was having (I was printing at 600dpi - standard - nothing fancy... remember, if I turned up the DPI/quality settings, it printed fine, but the standard settings were causing me grief!).</p> <p><a href="http://www.jrcresearch.net/downloads/printtest.txt" rel="nofollow noreferrer">Script</a></p> <p>or </p> <p><a href="http://www.jrcresearch.net/downloads/grid_print.pdf" rel="nofollow noreferrer">PDF</a></p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USJustin Carroll
    1. USJustin Carroll
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POPython/PDF Creation Using ReportLab - self-made grid prints with a pattern but looks fine on the screen
      1. USillya
      1. VTFavorite
    2. VO
      singulars
      1. POPython/PDF Creation Using ReportLab - self-made grid prints with a pattern but looks fine on the screen
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POPython/PDF Creation Using ReportLab - self-made grid prints with a pattern but looks fine on the screen
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload