Moderators:TrackerSupp-Daniel, Tracker Support, Paul - Tracker Supp, Vasyl-Tracker Dev Team, Chris - Tracker Supp, Sean - Tracker, Ivan - Tracker Software, Tracker Supp-Stefan
Forum rules DO NOT post your license/serial key, or your activation code - these forums, and all posts within, are public and we will be forced to immediately deactivate your license.
When experiencing some errors, use the IAUX_Inst::FormatHRESULT method to see their description and include it in your post along with the error code.
Hallo Alex,
I already know the link you sent me.
However, I am looking for a way to programmatically trigger the smoothing for exactly one document in one Editor.
Is there a way to do that?
AteBe
If the instance of an Editor is being launched in the separate process then there won't be any problems whatsoever. When you are launching it from the same process then their IPXV_Inst is the same, thus the settings for it also are the same for both of the documents.
Sasha - Tracker Dev Team wrote: ↑Tue May 14, 2019 8:08 am
If the instance of an Editor is being launched in the separate process then there won't be any problems whatsoever. When you are launching it from the same process then their IPXV_Inst is the same, thus the settings for it also are the same for both of the documents.
What we are trying to find out in this post is, if a workflow like the following is possible using the PDF-XChange Editor SDK:
1. Render a PDF without smooting in a Viewer a
2. Call some method a.smooth() to trigger smoothing once for the currently displayed content without setting any properties/settings.
You are telling how do you want to achieve the result, but what we need is what exactly do you want to achieve. Because as I explained previously - the settings (IPXV_Inst) are the same for each control in one process.
Hello,
we have two viewing-modes. The user can switch between them:
1. Original viewing mode: The PDFs are delivered as is and displayed using PdfXChange Editor including smoothing.
2. Prescaled viewing mode: The PDFs are converted (on the server-side) in pure-image PDFs with exactly the correct resolution (DPI) to fit the zoom (90%, 100%, etc) and screen resolution (96dpi, 120dpi, etc) the user currently uses. That way the rendering of very large PDF-documents can be done much quicker (almost instantaneous), because one pixel on the screen corresponds to exactly one dot in the prescaled PDF and smooting can be switched off. Also: The amount of data that needs to be transmitted between server and client is much smaller.
In addition to that we have two different PDF viewers within our application (both using an embedded PDFXChange Editor). Each one of these PDF viewers can have a different viewing mode. That's why we need to control smoothing separately for each embedded PDFXChange Editor.
In this scenario, turning off the smoothing won't give any significant improvements on the client, but on the other hand, zooming for like 125% without smoothing will corrupt the image before the server gives new information.
In this scenario, it will take quite a bit of time to rasterize all of the pages, create a PDF file with them and then give it back. Note that the images bloat the PDF file size greatly. And also, the server is doing quite a lot of unnecessary work like generating the PDF file. It would be a lot better to give the png files to some control on form that can handle images then generate the new PDF files. You also does not include that the Editor will have to render the images on pages that you gave him, which will be much slower then rendering text.
This scenario can give some benefits when rendering files with many path items like technical drawings. But again it would be much more faster to use just the rendered images and output them on some sort of Image control on your form.
Hello Alex,
I assure you that there are significant benefits to our approach, which have been verified in ten years of production.
Our users look at a lot of drawings in one day (thousands, sometimes even tens of thousands). The size of the PDFs we are talking about here is DIN A2 (or larger). We always use single page PDFs.
The main thing we minimize is the amount of time a white/empty page is shown between documents, because the constant flickering annoys our users a lot.
Unfortunately, we cannot use a pure image viewer because some data we display is not purely graphic and our users also want to use PDF-Annotations. If a user wants to view data quickly he/she uses prescaled viewing mode. If working with text elements is required the user switches to original viewing mode. Our document archive provides all data in image and PDF format to provide (no adhoc computations required - except for the scaling of images to the appropriate resolution needed).
If there was a way to render/rasterize a PDF in the background and then very quickly change the PDF view to the new pixels/content without any visible flickering, that would be ideal. Is that possible using the SDK?
Hello Sasha,
thanks for your reply. We have been evaluating setting "Synchronous Page Rendering" to "Yes", but it does not seem to make too much of a difference (if at all).
Please find attached our current preferences for rendering (Preferences-Rendering.jpg) and also a typical use case as a PDF (see attached PDF file). The (single-page) PDF is comprised of 6 drawing pages of one patent document combined with a few mock comments as embedded annotations. A typical user may look at several thousands of PDFs like the attached per day.
Questions:
1. Can we optimize the rendering preferences any further (with leaving "Smooth Line Art" and "Smooth Images" activated)?
2. Is it by accident that "Smooth Text" offer ClearType as an option? Does that mean that the OS (Windows) will do the smoothing/rendering of text? What is the exact difference to "Antialias (for monitors)"?
Regards,
AnKeilha
You do not have the required permissions to view the files attached to this post.
1) Smooth Line Art and Smooth Images won't do much difference. I'm afraid that the rendering can't be optimized further.
YOu can check out the DrawPagesCallback: viewtopic.php?f=66&t=29167&p=113820&hil ... ck#p113820
You can draw your information on the After flag, and you will draw over our rendered data. Though you cannot possibly know when we finished our rendering.
2) ClearType - we draw this, not Windows. As for the difference - open document with plain text and try switching them.
We were setting the zoom more than once, which resulted in a repaint for the document displayed and thus caused the white flicker in between displayed documents. PDFXChange was not the cause of the problem and its rendering performance is awesome - as always.