We’re currently evaluating this tool for purchase, and I’ve been running into a number of problems getting the output to match the source material. I’ve attached a ZIP file containing both the HTML source and the resulting PDF. If you view the HTML file in a web browser (IE, firefox, etc.) and then compare it to the PDF, the difference is significant.
field values overlapping on top of other cells/elements in the same row
half of the fields appear to be missing (off-page or hidden underneath other elements)
“border-radius” CSS style not working?
“text-align: left” CSS style not working in audit history TH classes
other minor spacing issues, like how “Demographics” and “Single-Line Entry” are right up against each other – in other tests I ran, they were so close that the solid border between them was hidden entirely.
Could someone please check and see what might be causing these problems? My conversion code closely follows the InLineHTML example:
var pdf = new Aspose.Pdf.Generator.Pdf();
pdf.IsLandscape = true;
pdf.Security = new Aspose.Pdf.Generator.Security();
pdf.Security.IsFormFillingAllowed = false;
var section = pdf.Sections.Add();
StreamReader r = File.OpenText(@"C:/test/input3.html");
var text = new Aspose.Pdf.Generator.Text(section, r.ReadToEnd());
text.IsHtmlTagSupported = true;
section.Paragraphs.Add(text);
pdf.Save(@"C:\test\output.pdf");
Thanks for your inquiry. It is recommended to use new DOM approach of HTML to PDF conversion. Please find attached resultant PDF for the reference, your reported issues are fixed in it.
However, unfortunately I have noticed that form fields (Checkboxes and Radio buttons) are not being rendered properly in output PDF. So we have logged a ticket PDFNEWNET-38091 in our issue tracking system for further investigation and resolution. We will notify you as soon as it is resolved.
In addition to above reply, It seems you are evaluating Aspose.Pdf without a valid license. Please note Aspose.Pdf evaluation version has
two limitations, evaluation watermark and at most four elements of any
collection can be viewed. You may also make a request for 30 days temporary license to evaluate our product without
any limitation. Please also check license implementation detail.
Please feel
free to contact us for any further assistance.
Yes, it seems the new DOM approach is limited without a license while the older method wasn’t – I’ve gone and requested a temporary license and it’s working now. I’m seeing other threads in this forum with problems where the fix is to use the DOM approach too… it might be worth looking into updating the inline HTML article in the “Docs” section to warn users about this and point them to the DOM method.
Anyway, I ran another test with the DOM approach and it does look much
better. I do see the control problems you mentioned, though… certain
checkboxes not displaying at all, and both checkboxes and radio buttons
not being “checked/selected” when they should be.
I have three questions if you don’t mind:
1) When is your next release scheduled, and what is the likelihood of the checkbox/radio issues being fixed in it?
2) The conversion process took ~90 seconds and bumped the filesize from 47 KB (html) to 205 KB (pdf). This is fairly slow. Running Optimize() or OptimizeResources() cut the filesize down to ~130 KB, but added another 10 seconds on to the processing time. Do you have any recommendations to make the process faster and/or more efficient?
3) Out of curiosity, in your sample code, are you setting the
height/width manually to approximate a Landscape layout, or is there a
separate option to specify Landscape? I had to look through these forums to figure out that Flatten() is used to make the document read-only, whereas the old method used “pdf.Security.IsFormFillingAllowed”.
Yes, it seems the new DOM approach is limited without a license while the older method wasn't -- I've gone and requested a temporary license and it's working now. I'm seeing other threads in this forum with problems where the fix is to use the DOM approach too... it might be worth looking into updating the inline HTML article in the "Docs" section to warn users about this and point them to the DOM method.
Thanks it is good suggestion, we will implement it after internal discussion.
jwills:
1) When is your next release scheduled, and what is the likelihood of the checkbox/radio issues being fixed in it?
We release new version of our APIs on monthly basis, mostly in first week of each month. Moreover, in reference to the resolution of your reported issue. we cannot share any timelines at the moment. As we have recently noticed the issue and it is pending for investigation. We will be able to share an ETA as soon as its resolution of your issue is completed.
jwills:
2) The conversion process took ~90 seconds and bumped the filesize from 47 KB (html) to 205 KB (pdf). This is fairly slow. Running Optimize() or OptimizeResources() cut the filesize down to ~130 KB, but added another 10 seconds on to the processing time. Do you have any recommendations to make the process faster and/or more efficient?.
We have noticed the issue and logged it as PDFNEWNET-38098 in our issue tracking system for further investigation and resolution. We will keep you updated about the issue resolution progress.
jwills:
3) Out of curiosity, in your sample code, are you setting the height/width manually to approximate a Landscape layout, or is there a separate option to specify Landscape? I had to look through these forums to figure out that Flatten() is used to make the document read-only, whereas the old method used "pdf.Security.IsFormFillingAllowed".
Yes you are correct, in new DOM approach you need to use PageInfo property of HtmlLoadOptions to set page dimensions. Moreover, Flatten() method is used to make form fields read only.
Please feel free to contact us for any further assistance.
jwills: