Strange Panel to Printer Behavior

[Lipko]

Hi all!

I started using the panel to printer method because I needed high quality pdf output of the front panel. It works okay apart from rotated strings, but I encountered a strange and pretty bad artefact. I have a graph on the front panel, and under some circumstances, "constant" lines appear on the graph in the generated pdf, see picture below (top: the front panel that is to be printed, bottom: the generated pdf). On the front panel itself, I don't see anything strange, no artefacts on the graph. This happens about 2 times per 15 prints. The graph data and everything is always the same, the only difference is the X scale range. I can set a range when the artefact wanishes. For the example below, there's no artefact with X scale set to 150... 210.

I don't know where I could screw up and what, or is it a known bug (2015 sp1)? If it's a known bug, is there a workaround?

Thanks for any hints in advance!

 

 

[Lipko]

Okay, I made an easy fix, I wonder if this thing will occur again.

So: simply keep only the curve data that's inside the x scale range.

[Lipko]

Hmm, that print to PDF method is pretty amazing, I wonder why it seems so unfinished (rotated texts become bitmaps, overlapping things may or may not become bitmaps, etc)

So: maybe everybody already knew that, but picture controls are actually vector based. Lines are pretty, smoth vector lines, texts are texts that will be selectable in the pdf, etc. I'm shocked....

[Rolf Kalbermatter]

On 6/26/2023 at 11:19 AM, Lipko said:

Hmm, that print to PDF method is pretty amazing, I wonder why it seems so unfinished (rotated texts become bitmaps, overlapping things may or may not become bitmaps, etc)

So: maybe everybody already knew that, but picture controls are actually vector based. Lines are pretty, smoth vector lines, texts are texts that will be selectable in the pdf, etc. I'm shocked....

There are many ways you can print and it is not entirely clear to me which one you use. If you use the method to have LabVIEW send a front panel to the (default) printer, what really happens is rather involved. LabVIEW has no idea if the printer is a real printer, using EPS, LPD/LPR, JetDirect or whatever else underlaying printer driver protocol. All it knows is that the printer driver supports a GDI interface (The Windows Graphic Device Interface specification that is also used to draw items on the screen) and it pretty much treats it exactly the same aside from some extra setup steps such as page size and orientation. What finally ends up on the printer is very specific on the quality of the printer driver and its ability to render each of the zig hundred GDI commands properly in a resulting output. It seems that the PDF printer driver you are using, does some shortcuts by not rendering everything itself but for instance letting rotated text be rendered by the Windows GDI subsystem itself and then reading the resulting bitmap and adding that into the PDF stream. A very valid procedure although of course not the highest quality result.

Other PDF printer drivers may be a bit more developed and translate this properly into direct PDF commands, but they may cost something.

Edited June 27, 2023 by Rolf Kalbermatter

[Lipko]

15 hours ago, Rolf Kalbermatter said:

There are many ways you can print and it is not entirely clear to me which one you use. If you use the method to have LabVIEW send a front panel to the (default) printer, what really happens is rather involved. LabVIEW has no idea if the printer is a real printer, using EPS, LPD/LPR, JetDirect or whatever else underlaying printer driver protocol. All it knows is that the printer driver supports a GDI interface (The Windows Graphic Device Interface specification that is also used to draw items on the screen) and it pretty much treats it exactly the same aside from some extra setup steps such as page size and orientation. What finally ends up on the printer is very specific on the quality of the printer driver and its ability to render each of the zig hundred GDI commands properly in a resulting output. It seems that the PDF printer driver you are using, does some shortcuts by not rendering everything itself but for instance letting rotated text be rendered by the Windows GDI subsystem itself and then reading the resulting bitmap and adding that into the PDF stream. A very valid procedure although of course not the highest quality result.

Other PDF printer drivers may be a bit more developed and translate this properly into direct PDF commands, but they may cost something.

Thanks for the comment and also the info about the GDI thing. I have a small issue with dashed lines appearing solid or very dense when printing (yes, I use the printer method) also present in DiAdem, and I will research if it's also related to GDI.

Edit: no, it's the printer that's causing the linestyle issue.

Edited June 28, 2023 by Lipko

[Rolf Kalbermatter]

9 hours ago, Lipko said:

Thanks for the comment and also the info about the GDI thing. I have a small issue with dashed lines appearing solid or very dense when printing (yes, I use the printer method) also present in DiAdem, and I will research if it's also related to GDI.

Edit: no, it's the printer that's causing the linestyle issue.

It may be the printer or its printer driver.