Hi,
we’re using L&L 22.
When printing (previewing) the list project, which has a dotted lines, the performance is really bad while scrolling the preview. If the lines are solid one, everything is working OK.
Has anyone encountered the same problem? Any workarounds?
Thank You
I’d not use dotted lines at all. They also used to bloat the PDF export. For my standard reports I switched to light grey lines which work great. IIRC, the reason for both (performance and PDF bloating) was that the dotted lines are drawn as single objects per dot.
Hey,
thanks for the reply.
Yes, we’re using the grey lines as you’ve mentioned. And yes, from profiling I found they draw it as ellipsis, which is weird, because GDI does have mechanism for dotted lines (or any custom pattern) while drawing lines, etc. which is pretty fast.
Had something to do with what it looks like when zoomed (as the GDI lines always look the same as they don’t know anything about ‘zoom’) and what different printers make of it. Can’t remember the details, though.
Hmm, AFAIK GDI lines could be “zoomed”. The zoom is only change of coordinates on the device context. I’ve done this before and there was not problem with it (as in preview times or print time).
What could be case here is, as you’ve mentioned, that maybe some printers with bogus drivers weren’t printing it right and therefor they are doing it using ellipses.
It’s indeed as @Gunther_Schwarze wrote:
To have consistent run widths and visible effects, these line types are translated into runs of lines and/or dots, which makes them nice, but slow. In addition, these lines or dots are translated to GDI+ objects for the preview, which makes them even nicer, but also even slower. Basically, they work fine when used as underlines for sums etc., however I wouldn’t recommend them as standard separator for tables.
If you’d like, feel free to add a request to the Idea Place category to add “normal” GDI drawn lines to the mix. The result may vary then hovever between printers, the preview and the export formats.
I see.
Thanks for the reply.
The problem with such PDFs is not only the speed, but for our customers it’s the file size. We have examples, where the size for 10 Pages raise from 200KB (solid lines) to 10’000KB (dotted lines). This is a file size which is often not possible to send by eMail.
Instead of defining each dot of a dotted line as a single PDF object, wouldn’t it make more sense to create a “dotted line” object and reference this?
Sure, this would be the solution. The problem is that at creation time it is not known that the current page will be used for PDF creation. It might be a preview file that is saved to PDF later in the process. However we plan to add the line information as additional metadata and avoid this problem that way. For the time being, usage of dotted lines is discouraged for PDF output.
Another solution could be adding some flag to PDF exporter which will use “lightweight rendering” (that is use the lines instead of ellipsis in this situation) of these objects.
