For document rendering we needed perfect path drawing capability as supported by the OS. FMX Canvas is great at many things, but has different limitations in path drawing, clipping, etc. across different platforms. With inputs through QC, we implemented native rendering across all platforms for the drawing capabilities we needed and now we have accurate and fast rendering across all platforms. The speed gains with native rendering on Android is phenomenal, plus that you can render in a background thread on Android with native rendering enables for a smooth enjoyable document viewing experience.
For document rendering we needed perfect path drawing capability as supported by the OS. FMX Canvas is great at many things, but has different limitations in path drawing, clipping, etc. across different platforms. With inputs through QC, we implemented native rendering across all platforms for the drawing capabilities we needed and now we have accurate and fast rendering across all platforms. The speed gains with native rendering on Android is phenomenal, plus that you can render in a background thread on Android with native rendering enables for a smooth enjoyable document viewing experience.
You can download the trial version here:
https://www.gnostice.com/XtremeDocumentStudio_Delphi.asp?show=downloads
Originally shared by Gnostice.com
We are pleased to announce a mega release of XtremeDocumentStudio Delphi. This release includes major enhancements in PDF rendering with native rendering for all FMX platforms - Win32/64, OS X, iOS and Android. We have added support for RAD Studio 10.2 Tokyo along with several enhancements in PDF rendering, and fixes in viewing, conversion, multi-language searchable PDF generation, Report Export and more.
Please see here for the full list of enhancements:
https://www.gnostice.com/XtremeDocumentStudio_Delphi.asp?show=history
You can download the free trial here:
https://www.gnostice.com/XtremeDocumentStudio_Delphi.asp?show=downloads
#iOS #Android #MacOS #Windows #PDF #Delphi
Girish Patil Thank you. The Apple PDF engine (as demonstrated for example by it's use in the Apple preview app) is not that good, and is certainly far from perfect. I often point to it's failures as a good case for why one would not want to use it use it (or anything that relies on it) to view a document of importance (such as a legal contract).
ReplyDeleteSimply put, one expects content to be rendered in these situations, and missing content is a cause for alarm.
While it can be argued that not even Adobe can measure up to the PDF 32000-1:2008 iso specification (considered to be the minimum gold published standard) for a compatible viewer, it can be said with all certainly that Apple's PDF engine does not.
I believe that there is only one valid rendering compatibly test, and that is to compare the resulting pixel values against a definitive source, where a perfect score could only be obtained when the pixel values compared exactly match that definitive source.
That said, Adobe's RIP is the gold standard that must be used to measure all other PDF and PostScript® rendering attempts against.
I have spent over three decades doing that.
I must admit, your output looks good.
As expert in this field, I must state that when using this method of rendering (handing it over to OS functions) it is highly unlikely to pass a rendering compatibly test, much less across different systems.
As I mentioned previously, even the conversion of numbers to call those functions affects accuracy (converting doubles to singles for example), and as you posted, indeed, you must make those conversions.
Some might argue that these conversions result in a very small margin of error, however, when you consider transformations that may be involved (especially at the charpath level), the margins may became significant, and with all certainty do affect the rendered output.
You said "perfect path drawing capability as supported by the OS"
I can believe that statement.
I was questioning how close (or far off) that actually is from definitive (when using your method).
Please know, I follow this with great interest.
As I said, at one time, my engine used the same methods, and I been considering adding this method back in (as an option).
Pixel perfect rendering is a very lofty goal.
My keen eye immediately noticed what I thought would be rendering differences (from what would be the definitive) when looking at the examples you posted, but I chalked most of that up to the conversion of screen-shots (sizing, and conversion to gif or whatever - it is not a lossless process). I would think that dot gain I see is (for sure) caused by screen-shot sizing.
Since 1985, I have developed a large number of compatibility tests for PostScript® and PDF, but I have none I was specifically thinking of. Of course, the arcto function is a very good one (I like that one, since I am unaware of anyone else outside of Adobe that has a 100% compatible function).
I think you mentioned dash, line caps and joins (and miterlimit?). It can be difficult to find truly compatible functions to do that work, although good results can often be obtained.
Honestly, I don't think the "average Joe" really cares about rendering accuracy. If it looks good, that's all that counts.
I do think the "average Joe" is totally unaware that many PDF products often fail to render some content, and on occasion, they get bit by that fact (legal contracts come to mind).
I am bound to say:
PostScript® is a registered trademark of Adobe Systems, Inc.
And:
Display PostScript® is a registered trademark of Adobe Systems, Inc.
But "Displayable PostScript"? I invented that!
TJoe(h^) - Developer of PDF and PostScript® engines, SDKs, and products for over 32 years.
ReplyDeleteJoe C. Hecht I understand what you are pointing to by pixel perfect as compared to an Adobe engine. I have that in my mind and we have done experiments with image comparison of an Adobe engine generated page image and of our products to automate the testing of rendering accuracy. The process is not complete and we will come back to that once we have the current planned viewer related work completed. We already know that won't be an easy process to automate ;). All rendering results passing the comparison test is another matter. Our .NET and Java products had an automated rendering test that was based on comparison of the newly generated image against a manually checked benchmark image generated by the product being tested and verified to be correct. This takes care of identifying regression with rendering and in an automated process. XtremeDocumentStudio Delphi has started to use that process now. So, what I can say at this point is we will be at it until we perfect it.
ReplyDeleteGirish Patil While I believe that absolute perfection (in this is case) is most likely unobtainable, I am very pleased to find a company where these sorts of results do matter, and who makes a commitment in trying to achieve perfection. This is a rare quality. Thank you.
ReplyDeletePlease keep us posted on your progress. As I said, having done this before, and specifically with the same fomat (PDF and , PostScript®), I follow with very great interest.
For the legal department at Adobe, please forward my "PS" below to Dr. John Warnok (pun intended):
PostScript® is a registered trademark of Adobe Systems, Inc.
TJoe(h^);
PS: Dear John, sorry to say the only surviving copy of that paper you wrote back in school (#3 of 6) was found earlier this year to have been partially eaten by insects. It was protected in a plastic box too. Very sad news indeed (I'm crying over it).