|
|
Rank: Member
Groups: Member
Joined: 10/17/2013
Posts: 22
|
Hi,
We are trying to embed our package in Kubernetes.
We must eliminate HtmlToPdf.UseClassicEngine() which causes failure.
The problem is the PDF created are blank.
Do I have to attache another engine instead of the classic, and how?
Thanks,
Yossi
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,217
|
Hi,
We no longer support classic engine. The classic engine was based on a WebKit release in 2011. We switched to Chromium browser engine in 2016 and the new Chromium engine is the only supported engine since 2017. Even with the new engine, there have been many update over the years in order to support newer Windows and Windows update patches. So it would not be a surprise that the 9 years old classic engine would stop functioning on some systems. As such you should consider switching to the current version instead.
Thanks!
|
|
Rank: Member
Groups: Member
Joined: 10/17/2013
Posts: 22
|
Hi,
That's exactly what I'm trying to do - use the Chromium engine instead of the classic engine.
Therefore I removed HtmlToPdf.UseClassicEngine() expecting the package will use the Chromium engine instead.
However nothing is rendered and I get empty pages.
My question is - what else should I do in order to activate usage of the Chromium engine?
Thanks,
Yossi
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,217
|
Hi,
You do not have to do anything to "activate" the Chromium engine. V16 was a transitional version that offers both engines and it would default to Chromium engine unless you explicitly calls UsesClassicEngine(). From V17 it only uses Chromium engine.
If you are getting blank PDF file, then it means something has failed. In that case you can try to do two things:
1. Update to the latest build first. There have been multiple Windows updates that broke our older version. So make sure you are on the latest build first;
2. Whenever the PDF conversion fails, you should get an exception. So please try to get details about the exception, including the exception message and stack trace. That will provide more information on what might be failing;
Thanks!
|
|
Rank: Member
Groups: Member
Joined: 10/17/2013
Posts: 22
|
Hi,
1. I tried your recent version. Producing the PDF worked fine, but its size was up to 5 times bigger the with 2016 version.
That's an issue for some of our customers.
2. No exceptions catch, and the PDF is Empty. Can I upload my sample somewhere?
Thanks,
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,217
|
Hi, The DLLs for the new version is indeed much bigger than the older version. This is due to the new version uses Chromium, which is a much more powerful and up to date browser engine and the old version uses a WebKit based browser engine that's almost 10 years old. Modern browser engine are extremely complex but unfortunately it also means they are quite big. Our distribution is fact is a lot smaller than other Chromium distribution because the code in our DLL is compressed (they are decompressed on the fly at runtime). I am not sure what you meant by "PDF worked fine" and "PDF is empty". So you always get an empty PDF file? You can follow these steps to send us sample project: https://www.essentialobjects.com/forum/test_project.aspxThanks!
|
|
Rank: Member
Groups: Member
Joined: 10/17/2013
Posts: 22
|
I sent the sample PDF and receive the answer:
"You will need to update to the current version. We have stopped supporting your version a long time ago."
When I wrote previously "...the size was up to 5 times bigger." I referred to the size of the PDF produced using EoPdf-2020 Vs EoPdf-2016 with the classic version and not to the new engine DLLs size.
e.g. converting a specific html produced a 5 MB PDF with EoPdf 2016 and a 26 MB PDF with EoPdf 2020.
That's an issue for some of our customers which currently prevent us from upgrading.
Is the PDF size issue it something that might be solved?
Which other advantages can we have by upgrading to EoPdf 2020?
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,217
|
Hi, I am sorry we misunderstood what you meant by file size. We thought you meant our DLL file size. We didn't realize you meant result PDF file size. For the PDF file size, you can send us both PDF file (from the old version and from the new version) and we can look into it to see what caused the big file size jump. See here for how to send test files to us: https://www.essentialobjects.com/forum/test_project.aspxThere have been numerous improvements in the new version comparing to your version. The most significant change between your version and the current version is the current version uses an update to date browser engine and the browser engine in your version is about 10 years old. So in a way the difference is similar to using a modern browser versus using IE 6. Beside this there have been many changes on our end that you can find in our change list page: https://www.essentialobjects.com/ChangeLog.aspxThanks!
|
|
Rank: Member
Groups: Member
Joined: 10/17/2013
Posts: 22
|
Hi,
I opened my sample in chrome and 'printed' it to PDF. The PDF file was also 5 times bigger.
So I guess it is an issues with the chromium engine.
Thanks for your support.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,217
|
There are reasons behind why the files are bigger. It could be more font data, or higher resolution image, etc. It doesn't just get bloated for no reason. Once you find out why the files are bigger, you may have options to reduce the size. For example, if the cause is higher resolution images, you may be able to reduce the image size by setting HtmlToPdfOptions.JpegQualityLevel to a lower value. If the cause is font data, you maybe able to reduce the file size by consolidate the font you use in your HTML.
|
|