Printing woes

Forum for the PDF-XChange Editor - Free and Licensed Versions

Moderators: TrackerSupp-Daniel, Tracker Support, Vasyl-Tracker Dev Team, Sean - Tracker, Paul - Tracker Supp, Chris - Tracker Supp, Tracker Supp-Stefan, Ivan - Tracker Software

Post Reply
Timur Born
User
Posts: 680
Joined: Tue Jun 26, 2012 1:50 pm

Printing woes

Post by Timur Born » Mon Sep 10, 2018 9:49 pm

Hello everyone!

I mentioned several time before that I don't entrust X-Change Editor with any color critical or large size printing jobs. One reason is the flawed color management, another reason is its bigger print job sizes due to how fonts are sent to printer drivers. What I did not expect, though, is that even forms/line drawings are sent as bitmap images to my HP PCL6 printer instead of proper vector data. And this has several negative ramifications.

The following print test document consists only of shapes/line drawings and text, there are no (bitmap) images present whatsoever.

http://zsory-furdo.hu/evcms_medias/uplo ... stfile.pdf
cups_testpage.JPG
Editor sends the whole document as bitmap image to my HP PCL6 printer, including the three shapes/line drawings on top of the page. Especially the black sun-star to the upper right is what made me aware of the problems; it printed with a strong blue hue out of Editor, but remained black out of Acrobat Reader.

The reason for the blue hue likely is two-fold:

- The HP PCL6 driver defaults to printing black and gray text and line drawings using only black toner, but "photos" - aka bitmap images - use all four toners (CMY + B) for black/gray colors. This is how I noticed that the whole page is printed as bitmap image instead of text and line drawings.

It also means that my printer is using colored toner to print toned grays and deeper blacks even when only black toner would be sufficient. This increases printing cost.

- When Editor prints bitmap images it likely applies its flawed color management which usually increases saturation of my prints out of Editor. This could have turned the moire of the sun-star to a visible blueish hue. I will have to test this further tomorrow, because the printer is too loud for the current late time.

There are more problems with this approach:

- The print job increases in size. The same testpage creates a print-job of only 0.3 mb coming from Adobe Reader, but 4.65 mb coming from Editor.
- Bitmap smoothing/antialiasing is applied by the print driver (defaults to being enabled) and in the case of the sun-star it is even necessary in order to print it at somewhat usable resolution.

And last but not least there is an even more exotic issue: All text inside the two boxes, the copyright text below the "Printed Using CUPS v1.3.x" line and inside the large C get Cleartype font antialiasing applied. Or rather, it gets the same kind of antialiasing applied that was used for on-screen antialiasing/smoothing by Editor. So if Cleartype is used in Editor (for screen viewing) then this text is printed with a red shadow on the left side of black lines and a blue shadow on the right side. And this happens regardless of whether the printer driver is using only black toner for the text or all four toner colors.

No idea why all the other text parts on the page are not affected by this screen smoothing oddness, but regardless of that all text on that page seems to be sent as bitmap graphic instead of font uploads or outlines. And yes, text rendering mode is set to "Auto".

Curious side-note: "Print as Image" is not enabled, but enabling it decreases Editor's print-job size from 4.65 mb to 4.57 mb. So there really seem to be no benefits of how Editor is handling this whole print-job whatsoever, only drawbacks.

User avatar
Paul - Tracker Supp
Site Admin
Posts: 4988
Joined: Wed Mar 25, 2009 10:37 pm
Location: Chemainus, Canada
Contact:

Re: Printing woes

Post by Paul - Tracker Supp » Tue Sep 11, 2018 5:57 pm

Hi Timur,

Ivan is looking into this . We have seen that some items that should not be, are in fact being rasterized. This is not a trivial investigation and I would ask your indulgence while we do the leg work.
_________________
If posting files to this forum - you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded - thank you.

Best regards

Paul O'Rorke
Tracker Support North America
http://www.tracker-software.com

User avatar
Paul - Tracker Supp
Site Admin
Posts: 4988
Joined: Wed Mar 25, 2009 10:37 pm
Location: Chemainus, Canada
Contact:

Re: Printing woes

Post by Paul - Tracker Supp » Tue Sep 11, 2018 8:29 pm

Hi again Timur,

we have corrected the issue that was causing rasterizing of items that should not be rasterized. The fix will be available in the next build 7.0.327 slated for release the beginning of October.

Thanks again for the detailed work in bringing this to our attention.
_________________
If posting files to this forum - you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded - thank you.

Best regards

Paul O'Rorke
Tracker Support North America
http://www.tracker-software.com

Timur Born
User
Posts: 680
Joined: Tue Jun 26, 2012 1:50 pm

Re: Printing woes

Post by Timur Born » Tue Sep 11, 2018 9:14 pm

Thanks for the quick fix and hint on a release date for the next version.

Three questions:

- That gradation bar in the upper center should be a shape, but Editor does not identify it as any image, text or shape content when I try the corresponding select option of the content pane. What is it then?

- What about part of the text getting on-screen antialiasing applied? Is this fixed as well?

- Which elements did you identify as "should be rasterized" and which as "should not be rasterized"? Since there are only shapes and text present I wonder why anything needs rasterization at all?! Especially since I set font rendering to "Auto", hoping to force Editor to sending the text (and corresponding font uploads) to my printer (driver) directly.

User avatar
Paul - Tracker Supp
Site Admin
Posts: 4988
Joined: Wed Mar 25, 2009 10:37 pm
Location: Chemainus, Canada
Contact:

Re: Printing woes

Post by Paul - Tracker Supp » Tue Sep 11, 2018 11:14 pm

Hi Timur,

regards your question:
- That gradation bar in the upper center should be a shape, but Editor does not identify it as any image, text or shape content when I try the corresponding select option of the content pane. What is it then?
that gradient is of a type "Shading". We will be adding this to the Editor in due course. It won't make it for 7.0.327 though.
What about part of the text getting on-screen antialiasing applied? Is this fixed as well?
Yes - it should not have been rasterized and won't be as of 7.0.327
- Which elements did you identify as "should be rasterized" and which as "should not be rasterized"? Since there are only shapes and text present I wonder why anything needs rasterization at all?! Especially since I set font rendering to "Auto", hoping to force Editor to sending the text (and corresponding font uploads) to my printer (driver) directly.
Ivan says this was quite complex and rather a lot had to be done here. I did not get the details. I saw progressive iterations of the print jobs as they worked on it and I have to say that the final result is absolutely beautiful. To my eyes it is indistinguishable from the Adobe printed version, that includes a better colour on the colour wheel, sharp text and no red shadow on the left side of black lines and a blue shadow on the right side where it was seen before. Additionally the radial lines are now clear and sharp as in the print from Adobe and the blue hue is gone.

I am looking forward to your feedback when you put 7.0.327 through the wringer come October.
_________________
If posting files to this forum - you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded - thank you.

Best regards

Paul O'Rorke
Tracker Support North America
http://www.tracker-software.com

Ivan - Tracker Software
Site Admin
Posts: 3617
Joined: Thu Jul 08, 2004 10:36 pm
Location: Vancouver Island - Canada
Contact:

Re: Printing woes

Post by Ivan - Tracker Software » Wed Sep 12, 2018 4:54 am

- Which elements did you identify as "should be rasterized" and which as "should not be rasterized"? Since there are only shapes and text present I wonder why anything needs rasterization at all?! Especially since I set font rendering to "Auto", hoping to force Editor to sending the text (and corresponding font uploads) to my printer (driver) directly.
Yes, in your document only shades should be rasterized, but due to an error in the code, extra items were rasterized too, and that resulted the quality in you have. That is fixed now and the fix will be included in build 327.0
Tracker Software (Project Director)

When attaching files to any message - please ensure they are archived and posted as a .ZIP, .RAR or .7z format - or they will not be posted - thanks.

Timur Born
User
Posts: 680
Joined: Tue Jun 26, 2012 1:50 pm

Re: Printing woes

Post by Timur Born » Wed Sep 12, 2018 7:35 am

Thanks for the quick fix, Ivan! I am looking forward to the next version.

User avatar
Tracker Supp-Stefan
Site Admin
Posts: 13861
Joined: Mon Jan 12, 2009 8:07 am
Location: London
Contact:

Re: Printing woes

Post by Tracker Supp-Stefan » Wed Sep 12, 2018 10:06 am

:D

Arnold
User
Posts: 717
Joined: Tue Jun 09, 2009 3:53 am
Location: Florida

Re: Printing woes

Post by Arnold » Mon Sep 17, 2018 3:14 pm

Would the bitmap problem discussed here explain why I have always had bad results when printing color documents to priPrinter from the Editor? I thought it was a filter of some sort causing the blurriness. Please see attached.

I have always run print jobs through priPrinter because I need it's features. Because of the results shown in the file attached, I still print all color pdf's with the Viewer. Most "print" jobs for me consist of creating 'n' up pdf's. I also have size constraints, so the Merge feature often will not work.

Just curious. Thanks.
Attachments
priPrinter.pdf
(403.45 KiB) Downloaded 51 times

Timur Born
User
Posts: 680
Joined: Tue Jun 26, 2012 1:50 pm

Re: Printing woes

Post by Timur Born » Mon Sep 17, 2018 6:06 pm

Sure looks that way.

User avatar
TrackerSupp-Daniel
Site Admin
Posts: 3006
Joined: Wed Jan 03, 2018 6:52 pm

Re: Printing woes

Post by TrackerSupp-Daniel » Mon Sep 17, 2018 6:22 pm

I am inclined to agree, It certainly does appear to be the same issue.

Have a great day!
Daniel McIntyre
Support Technician
Tracker Software Products (Canada) LTD

Sales: +1 (250) 324-1621
Fax: +1 (250) 324-1623

Timur Born
User
Posts: 680
Joined: Tue Jun 26, 2012 1:50 pm

Re: Printing woes

Post by Timur Born » Tue Oct 02, 2018 5:57 pm

327 does not seem to fix this issue.

User avatar
TrackerSupp-Daniel
Site Admin
Posts: 3006
Joined: Wed Jan 03, 2018 6:52 pm

Re: Printing woes

Post by TrackerSupp-Daniel » Tue Oct 02, 2018 6:16 pm

Thank you for reporting this, we will look further into it and reopen the case if necessary.
Best Regards.
Daniel McIntyre
Support Technician
Tracker Software Products (Canada) LTD

Sales: +1 (250) 324-1621
Fax: +1 (250) 324-1623

User avatar
Paul - Tracker Supp
Site Admin
Posts: 4988
Joined: Wed Mar 25, 2009 10:37 pm
Location: Chemainus, Canada
Contact:

Re: Printing woes

Post by Paul - Tracker Supp » Tue Oct 02, 2018 7:11 pm

Hi Timur,

are you absolutely 100,000% sure you are running 7.0.327? I just printed your test page again using 327 and the result is spectacularly different to the previous build.

As I am sure you can appreciate, scanning a printed result is not going to give an idea representation of the paper print job, but you should be able to see that there is a vast improvement on the previous results.

This is a 600 DPI scan. Even this shows improvement, though the scanning does not do the printed job justice.
Image

For me the colours are stronger, the blue hue is gone, the characters are sharper as are the radial lines. Arnold, or anyone else reading this, do you also see no improvement?

I am somewhat at a loss to understand how you can not be seeing any difference between this and the previous result.
_________________
If posting files to this forum - you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded - thank you.

Best regards

Paul O'Rorke
Tracker Support North America
http://www.tracker-software.com

Timur Born
User
Posts: 680
Joined: Tue Jun 26, 2012 1:50 pm

Re: Printing woes

Post by Timur Born » Tue Oct 02, 2018 8:00 pm

- deleted everything I wrote -

Turns out that from the many, many, many test prints I did lately the option to "print as image" was still enabled. So the blame is on me for not testing 327 properly, sorry for that.

User avatar
Paul - Tracker Supp
Site Admin
Posts: 4988
Joined: Wed Mar 25, 2009 10:37 pm
Location: Chemainus, Canada
Contact:

Re: Printing woes

Post by Paul - Tracker Supp » Tue Oct 02, 2018 8:20 pm

Not to worry Timur, you are keeping us on our toes! ;-)

So I take it then that you are happy with the improvements?
_________________
If posting files to this forum - you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded - thank you.

Best regards

Paul O'Rorke
Tracker Support North America
http://www.tracker-software.com

Timur Born
User
Posts: 680
Joined: Tue Jun 26, 2012 1:50 pm

Re: Printing woes

Post by Timur Born » Tue Oct 02, 2018 8:43 pm

I only did some very quick tests yet. There are some issues introduced with the new rendering. You might have noticed in your own scan that the resolution towards the center of the upper right sunstar decreased compared to the previous (pre 327) rasterized version, or at least replaced aliased lines with a big black blob.

With Adobe Reader this can be vastly improved by printing to a Postscript driver instead of a PCL6 driver. In Editor no such improvement happens. I will upload a scan of the Acrobat PS version for comparison with your Editor version.

On a curious side-note: Regardless of what driver I try (dedicated 2016 PCL6, Universal 2018 PCL6 or Universal 2018 PS) that sunstar is always interpreted as "text" instead of "graphic" (aka vector) by the HP drivers, coming both from Editor or Acrobat Reader.

Timur Born
User
Posts: 680
Joined: Tue Jun 26, 2012 1:50 pm

Re: Printing woes

Post by Timur Born » Tue Oct 02, 2018 10:15 pm

Printing to Postscript printer: Acrobat (left) vs. Editor (right)

Resolution is increased, especially towards the center of the circle and where line width and spacing is concerned.

I suspect that Editor is not capable of sending native Postscript while Acrobat Reader specifically is (Advanced Print dialog)?!

The rasterization of version 326 had the advantage that in combination with the HP driver's anti-aliasing (for bitmap images) it rendered the whole circle closer to Acrobat's Postscript version, even improving over it in some areas, but looking more "busy". I tried to mimic that rasterization by using "Print as image", but 327 keeps producing the low resolution PCL version with the rather large black center area and unevenness of line spacing.

So overall: Yes, improved, but at the same time showing a weakness of Editor that previously was concealed by its involuntary pre-rasterization.
Attachments
PS_acrobat_vs_editor.jpg

User avatar
Paul - Tracker Supp
Site Admin
Posts: 4988
Joined: Wed Mar 25, 2009 10:37 pm
Location: Chemainus, Canada
Contact:

Re: Printing woes

Post by Paul - Tracker Supp » Tue Oct 02, 2018 10:36 pm

Hi Timur,
I suspect that Editor is not capable of sending native Postscript while Acrobat Reader specifically is (Advanced Print dialog)?!
You are correct. We do not use native Postscript. Comparing the printed result from all three, Adobe Reader, Foxit and our Editor without using Postscript our print looks to me identical to Adobe and superior to Foxit.

We are satisfied with the quality, it matches or exceeds our competitors. We are not likely to make further changes at this time.

hth
_________________
If posting files to this forum - you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded - thank you.

Best regards

Paul O'Rorke
Tracker Support North America
http://www.tracker-software.com

Timur Born
User
Posts: 680
Joined: Tue Jun 26, 2012 1:50 pm

Re: Printing woes

Post by Timur Born » Tue Oct 02, 2018 10:53 pm

Maybe consider adding the previously "accidental" rasterization as an option? Because depending on the printer driver (settings) the pre-rasterization of 326 can be superior to the vectors of 327.

326 rasterized version left (bitmap printing manually set to pure black and driver anti-aliasing enabled by default) vs. 327 vectors right:
Attachments
Editor_rasterized_vs_vectors.jpg

User avatar
Paul - Tracker Supp
Site Admin
Posts: 4988
Joined: Wed Mar 25, 2009 10:37 pm
Location: Chemainus, Canada
Contact:

Re: Printing woes

Post by Paul - Tracker Supp » Tue Oct 02, 2018 11:28 pm

This is your lucky day Timur....

Ivan has made an change that will be available in 7.0.327.1, that if you print to a Postscript printer, we will automatically use the old algorithm for line width when it is set to zero.

This should give you what you are looking for.
_________________
If posting files to this forum - you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded - thank you.

Best regards

Paul O'Rorke
Tracker Support North America
http://www.tracker-software.com

Arnold
User
Posts: 717
Joined: Tue Jun 09, 2009 3:53 am
Location: Florida

Re: Printing woes

Post by Arnold » Wed Oct 03, 2018 3:16 am

I printed the test file to priPrinter using build 327 and it was just as good as the previous results with the Viewer (see attached). The settings used in 327 were Auto 300 dpi. I have never been able to achieve results like that with the Editor before.

When I viewed the attached file though I got a surprise. Everything looks good in Fit Width view, but not in Full Page view (see below). The radial lines are just a black circle in Fit Page view. Does not happen in Acrobat or Sumatra. Happens in the Editor (build 327) in both Windows XP & 7. Happens in Viewer also. Seems to be related to view magnification. Over here at 100% it is mostly a black dot, and is a black dot at 75%. Is this supposed to be this way?
2018-10-02 22_54_46-Greenshot.png
Thanks.
Attachments
327 & 326 Viewer Comparison.pdf
(446.45 KiB) Downloaded 36 times

Timur Born
User
Posts: 680
Joined: Tue Jun 26, 2012 1:50 pm

Re: Printing woes

Post by Timur Born » Wed Oct 03, 2018 8:33 am

The reason for the sun-star to turn black at small magnifications is because of resolution limits and that Editor draws those thin lines as thick lines. You will get similar (but still somewhat better) results in Acrobat Reader when you enable the "Enhance Thin Lines" option. Editor needs to learn to draw thin lines, currently it turns lines thinner than 3 point into 3 point ones, which then is somewhat countered by anti-aliasing but not enough to keep the circle from turning black.

The reason why 326 looks better is because of the accidental rasterization, which seemed to do quite a good job on the sun-star compared to the rasterization method used in 327.

User avatar
Tracker Supp-Stefan
Site Admin
Posts: 13861
Joined: Mon Jan 12, 2009 8:07 am
Location: London
Contact:

Re: Printing woes

Post by Tracker Supp-Stefan » Wed Oct 03, 2018 8:49 am

Hello Timur, Arnold,

Thanks for your comments and observations.
Indeed at zoom levels of 125% and up - the black central part of this object is comparable in Adobe and our products, but at 100% or less - Adobe does handle it better.
As far as I know from my conversations with the devs is that we use different anti aliasing algorithms, which are faster, and in most cases do produce comparable results, but of course there are some extreme cases like this one - where one approach wins over the other.

I will bring this up for discussion on the next meeting though I can't promise we will be able to make any significant changes to this rendering in the immediate future.

Regards,
Stefan

Timur Born
User
Posts: 680
Joined: Tue Jun 26, 2012 1:50 pm

Re: Printing woes

Post by Timur Born » Wed Oct 03, 2018 11:02 am

I think the main issue that Editor draws those lines too thick to begin with, anti-aliasing can only do so much to correct this if the basis is already flawed. As long as your lines are even thicker than what Acrobat draws using "Enhance Thin Lines" this will remain problematic. This is a bug of your line drawing engine and needs to be addressed first.

User avatar
Tracker Supp-Stefan
Site Admin
Posts: 13861
Joined: Mon Jan 12, 2009 8:07 am
Location: London
Contact:

Re: Printing woes

Post by Tracker Supp-Stefan » Wed Oct 03, 2018 1:13 pm

Hello Timur,

If the lines are horizontal or vertical - we will only use 1px width, but when they are at an angle - we will obviously need to use a bit more, and some antialiasing.
The image below shows a comparison of the same red line as seen in Adobe and the Editor. The image was zoomed to 800% in MS Paint.
Obviously adobe is also using '3 pixels' on each horizontal line - but theirs are softer. So I would not call this a bug - but rather differences in the algorithms provided giving different results in extreme cases as the one discussed here rather than a bug.
This is is no way implying we will not look at this and try to improve it further!

As I said - I will bring this up for discussion later in a meeting and keep you posted with the results!

Cheers,
Stefan
Attachments
Adobe_vs_Editor.png

Timur Born
User
Posts: 680
Joined: Tue Jun 26, 2012 1:50 pm

Re: Printing woes

Post by Timur Born » Wed Oct 03, 2018 8:19 pm

Editor turns 3 pixel lines into 1 pixel + 2 pixels of gray for anti-aliasing. Anti-aliasing thins the lines that started too thick to begin with. "Enhance Thin Lines" is permanently enabled.

Acrobat Reader turns 1 pixel lines into 1 pixel + *occasionally* one or two pixels of gray for anti-aliasing, even with "Enhance Thin Lines" enabled some parts of the original black lines are anti-aliased to gray. Anti-aliasing thickens the lines that started thin, but only at some points. If lines are less than 1 pixel then Acrobat turns the 1 pixel of black into 1 pixel of gray and *then* applies anti-aliasing. Acrobat's approach and results are superior to Editor's.

Here is a comparison of Acrobat using "Enhance Thin Lines" with and without anti-aliasing vs. Editor with and without anti-aliasing. Acrobat introduces less aliasing and less anti-aliasing artifacts. The version without anti-aliasing also introduces less aliasing and its lines are thinner (even with "Enhance Thin Lines" being enabled). Make sure to look at these at 100% magnification, preferably outside a browser.
Attachments
sunstar_ar_vs_editor.jpg

Ivan - Tracker Software
Site Admin
Posts: 3617
Joined: Thu Jul 08, 2004 10:36 pm
Location: Vancouver Island - Canada
Contact:

Re: Printing woes

Post by Ivan - Tracker Software » Thu Oct 04, 2018 10:04 pm

Will work on our rendering, especially on non-aa mode.
Tracker Software (Project Director)

When attaching files to any message - please ensure they are archived and posted as a .ZIP, .RAR or .7z format - or they will not be posted - thanks.

Timur Born
User
Posts: 680
Joined: Tue Jun 26, 2012 1:50 pm

Re: Printing woes

Post by Timur Born » Sat Oct 06, 2018 8:10 am

Great news, thank you! Several of my customers are architects, so lots of lines (CAD) are common in their PDF files.

User avatar
Tracker Supp-Stefan
Site Admin
Posts: 13861
Joined: Mon Jan 12, 2009 8:07 am
Location: London
Contact:

Re: Printing woes

Post by Tracker Supp-Stefan » Mon Oct 08, 2018 10:42 am

You are welcome Timur!

And thanks for all the sample files and helping us improve our products!

Cheers,
Stefan

Timur Born
User
Posts: 680
Joined: Tue Jun 26, 2012 1:50 pm

Re: Printing woes

Post by Timur Born » Wed Sep 04, 2019 10:11 am

Paul - Tracker Supp wrote:
Tue Sep 11, 2018 11:14 pm
that gradient is of a type "Shading". We will be adding this to the Editor in due course. It won't make it for 7.0.327 though.
This seems to be implemented now. Thanks for that. It's also worthwhile to emphasize that Editor draws this particular combination of shadings without a gap, while Adobe introduces a gap. So Editor's rendering is superior here.

Are there any plans to support proper "thin lines" anytime soon? Why is the "Enhance thin lines" option even present when it serves no purpose?

On a side note: I just did a quick performance test printing an image heavy 642 pages document to a HP PCL6 Color driver. Editor's average CPU load is slightly higher than Adobe Reader's combined (3 processes) average CPU load. Editor overtakes Reader at around half the document, thus printing slightly faster. But the resulting print jobs are 2.46 gb for Editor and only 1.66 gb for Reader.

User avatar
TrackerSupp-Daniel
Site Admin
Posts: 3006
Joined: Wed Jan 03, 2018 6:52 pm

Re: Printing woes

Post by TrackerSupp-Daniel » Fri Sep 06, 2019 5:37 pm

Hello Timur,

Glad to hear you are enjoying the new functions!

Currently the Enhance thin line option does indeed not do anything. As it is not harming anyone by being present, it is simply something that we have forgotten to remove (or hide) from the UI as time went on. At the moment we do not have a timeline for when it will be working.

Regarding the printing you described there. I am unsure how the size when printing to an HP color driver would have any effect on the physical output of the file. Arguably, if we are able to send the print data faster, with a reduced CPU load, that should generally be regarded as better, no?
The likely reason for the difference in CPU usage and processing time is likely a difference in compression levels, I cannot speak for Adobe, but we try to avoid excessive compression when printing a document so that it can be printed as accurately as possible by whichever printer is in use. Of course sometimes it is necessary, but we try our best to keep it to a minimum.

I understand that sending a 2.5gb file to a printer is not ideal, but anyone sending an image heavy 600+ page document should have a printer capable of handling a file that size to begin with (even basic printer models these days can handle a single file being 2~8gb in size) or alternatively be capable of splitting the document into two or more smaller print jobs.

Kind regards,
Daniel McIntyre
Support Technician
Tracker Software Products (Canada) LTD

Sales: +1 (250) 324-1621
Fax: +1 (250) 324-1623

Timur Born
User
Posts: 680
Joined: Tue Jun 26, 2012 1:50 pm

Re: Printing woes

Post by Timur Born » Sat Sep 07, 2019 10:37 am

Actually Editor's CPU load (one process) is slightly higher than Adobe (3 processes). It could be argued that 3 processed are better served to multiple CPU cores. But I am fine with both.

That Editor regularly produces larger prints and thus takes longer for the printer to process is more of a drawback. Because even when Editor manages to slightly overtake Reader in printing to the print driver, the large chunk of data still has to be processed by the printer, which then takes longer.

Fortunately I do not print these large files at all, I was rather curious about the comparison. I do sometimes have prints that take longer to process by the printer when coming from Editor, though, which usually can be attributed to the print size.

As long as Editor does not support "thin lines" (it practically always "enhances" them), Reader will be better for displaying and printing thin line objects.

User avatar
TrackerSupp-Daniel
Site Admin
Posts: 3006
Joined: Wed Jan 03, 2018 6:52 pm

Re: Printing woes

Post by TrackerSupp-Daniel » Mon Sep 09, 2019 7:18 pm

My apologies for misreading that Timur.

Thank you for the detailed feedback, I will forward this to the Development team so they can use it while working on improvements in all areas.
As usual, I cannot provide any timelines on feature requests, so I am unable to speak for thin lines management options you mentioned earlier.

Kind regards,
Daniel McIntyre
Support Technician
Tracker Software Products (Canada) LTD

Sales: +1 (250) 324-1621
Fax: +1 (250) 324-1623

Post Reply