Thanks for your inquiry. I have tested your scenario with shared HTML using Aspose.Pdf for .NET 11.4.0 and managed to observe the reported exception. For further investigation, I have logged an issue in our issue tracking system as PDFNEWNET-40426 and also linked your request to it. We will keep you updated via this thread regarding the issue status.
We are sorry for the inconvenience caused.
Thanks for your reply!
Hi Kuna,firstname.lastname@example.org:But bugs like this are shaking our confidence in recommending your tools for development especially for something that is direct from your documentation. Do you guys not do unit testing etc? Looking at other issues I see on the forum and our own, we have no time estimates for any of the fixes - which makes it hard to use your tools. At least can you propose a work around so we can use it in the mean time?
TableAbsorber is used to manipulate table in existing PDF file. However the product team will investigate the problem and figure out the reasons causing earlier reported email@example.com:How do you propose we use tableabsorber to visit tables without running into this issue? Is there any other way to go through the tables?
Can you please share the other issue ID’s so that I can get the latest status and share the results. We are sorry for your firstname.lastname@example.org:I am tasked with evaluating Aspose.PDF for our needs and I already have run across so many bugs (reported separately in different threads) and left with no idea when these bugs will be fixed. But the bigger question I have is, why am i running across so many issues when I thought this product is very mature?
Thanks for your reply.
Thanks for your reply.
I think you have not answered my questions. I am not interested in your answer regarding what Aspose.PDF does GENERALLY but interested more in what your team has found in terms of HTML to PDF conversion differences using Aspose.Word vs Aspose.PDF. Please restrict your answer to only this functionality as our need are based on this for now.
For the issues we have come across with Aspose.PDF, we have found Aspose.Word seems to handle them better but that doesn’t mean Aspose.Word is better in this case overall as we do not have the inner knowledge of either product to make a judgement call. I am sure Aspose.Words handles other areas of HTML conversion worse than Aspose.PDF - it’s that we don’t have the resources to test everything during this evaluation phase.
What we need is your team to provide information that you probably already have comparing what areas Aspose.PDF is better at in converting HTML to PDF vs Aspose.Word. Given both products are created by you, and in this case, the functionality in question is the same, I would assume your team would have the expertise to outline to us so we can make the decision.
Thanks for sharing the details and sorry for the delayed response.
Aspose.Pdf for .NET is being widely used by many customers for HTML to PDF conversion and there have been few cases where customers have reported that API is not honoring some HTML and CSS tags during conversion. Among these issues, there have been many scenarios that were investigated and resolved and some are still under investigation and hopefully, they will be resolved soon. Now concerning supported features for Aspose.Pdf for .NET, please visit
- Supported HTML features
- Supported CSS features
- CSS referencing during conversion
- HTML to PDF conversion - Known Issues
Frankly speaking, we do not have any comparison document between features of Aspose.Pdf and Aspose.Words but I have asked my fellow worker from Aspose.Words team to share required information for HTML to PDF conversion using Aspose.Words.
What can we do on our end to get better support to help us answer some of these questions? Or elevate priority of the items we have raised? Does getting a subscription help with either? Or do we need to go with other support packages? Please provide details, as we want to make a decision soon.
All the issues reported by our customers are equally important for us and the team will surely consider investigating your reported issue as per their schedule. As soon as we have some further updates, we will let you know.
Thanks for your post.
Thanks for the reply.
The HTML parser is fully based on official specification (https://www.w3.org/TR/html5) and supports the list of all available tags (see.: section 4 of the specification), except several are not supported by pdf-renderer for instance: KEYGEN, OUTPUT, PROGRESS, METER, RUBY and some states of the INPUT element such as: color; password; date; time; embedded content like: TRACK, SOURCE, AUDIO, which are currently not supported.
Furthermore, the CSS is also based on official specification. At first we implemented CSS2.1 specification and the list of the supported properties (https://www.w3.org/TR/CSS2/propidx.html) except ‘aural’ group (speech-rate, voice-family etc.). Now, we are focused on implementation a new features and rendering behaviors from CSS3 specification (https://www.w3.org/Style/CSS/current-work). Unfortunately, this part of the w3c is under development and the most of the css-properties are in experimental mode, their behavior is not defined properly and they keep changing very quickly, but we are trying our level best to keep these properties up to date.
Now concerning to list of problems in new DOM approach during HTML to PDF conversion, there have been some scenarios where customers have reported problems and from time to time, we keep on fixing them and in case you are facing problems in this area, please share the details and we will be more than happy to help you out in this regard.
On other hand, we really have a few features that we don’t support such as
’css3-animations’, because the output (pdf) format is static and can’t support the animation in the same way as browsers; or ‘css3-speech’ that is responsible for aural presentation of information.