We're sorry Aspose doesn't work properply without JavaScript enabled.

Free Support Forum - aspose.com

IsHtmlTagSupported- FontName and FontSize

I’m having difficulty getting what worked in version 2.2 to work in our newly upgraded version 8.5 of Aspose.Pdf.

Having set a font name and size for a text element I find that these values are ignored if IsHtmlTagSupported is set to true.

If, however I set UseTextInfoStyle=“true”, the font name and size are correct but all the HTML tags are then ignored.

This is the c# code demonstrating the issue:

//Instantiate the Pdf instance
Pdf pdf = new Pdf();

Aspose.Pdf.License license = new Aspose.Pdf.License();

//Bind the XML and XSLT file
pdf.BindXML(@“c:\temp\test.xml”, null);

//Save the resultant PDF

and the XML:

PageHeight=“1050” >

This is the basic text.


This is <span style=“color: red;”>also</span> test text with IsHtmlTagSupported=“true”.


This is <span style=“color: red;”>also</span> test text with IsHtmlTagSupported=“true” and UseTextInfoStyle=“true”.

As you can see from the attached screenshot, only the first line is correct.

I am expecting the font name and size to be inhirited in the HTMLand this is not happening.

Your help would be appreciated.

I’m finding the same bug.

FontName, Color, IsTrueTypeFontBold attributes are ignored if IsHtmlTagSupported=“true”. (Everything is black Times Roman instead of white Verdana). I guess any other attribute is ignored. If I take out IsHtmlTagSupported, the other attributes work properly.

Hi there,

Sorry for the inconvenience faced. While using the latest version of Aspose.Pdf for NET 8.5.0, I've managed to reproduce the reported font issue on my side and logged it in our bug tracking system as PDFNEWNET-35944 for further investigation and resolution. I've also linked your request to this issue and you will be notified via this thread as soon as it is resolved.

Please feel free to contact us for any further assistance.

<span style=“font-size:10.0pt;font-family:“Arial”,“sans-serif”;mso-fareast-font-family:
“Times New Roman”;mso-ansi-language:EN-US;mso-fareast-language:EN-US;
mso-bidi-language:AR-SA”>Best Regards,

I have the same issue. Please notify me as well. Thanks.

Hi there,

Thanks for your request. We are glad to update you that above reported issue has been resolved and it’s fix will be available in upcoming release of Aspose.Pdf for .NET .i.e. 8.6.0. Hopefully, after successful testing it will be release in coming week. However we will update you as soon as it’s published and gets available for download.

Thanks for your patience.

Best Regards,

The issues you have found earlier (filed as PDFNEWNET-35944) have been fixed in Aspose.Pdf for .NET 8.6.0.

This message was posted using Notification2Forum from Downloads module by Aspose Notifier.

I have just been able to revisit this issue and I agree, the first of the two issues reported has been fixed.

However, the second has not.

If you use the supplied XML to create a PDF you will find that the third line has the correct font inherited from the XML BUT the HTML tag in the text has been ignored. The HTML should set the colour of the word ‘also’ to red as in the second line. This was reported in line 3 y original post.

Therefore, the Aspose PDF component is still not working as is should.

Hi Mark,

Thanks for your inquiry. Please use IfHtmlTagSupportedCssWinsOnFirstLevelChildren=“true” attribute in textblock. It will affects the necessary color of font and will fix the use of IsHtmlSupported and TextInfoSyle together. Please check sample XML and output PDF file for the reference.

Please feel free to contact us for any further assistance.

Best Regards,


is IfHtmlTagSupportedCssWinsOnFirstLevelChildren still supported especially in XSLT? it is nowhere mentioned in a ducumentation and it dont work for Aspose.Pdf 9.3. I have problems with getting html-style working correct in another forum thread.

Thanks a lot in advance

Hi Alex,

Please share the resource XSLT or the other forum thread in which you have explained this problem, so that we can test the scenario and share our findings. We are sorry for this inconvenience.