I'm using latest version 9.9.1.5
of Saxon XSLT processor to process some XML
files in my WPF project on VS2019 - ver 16.3.10
. The processor correctly processes the XML files. But when I use the exact same code on a VSTO project with exact same files and exact same version of Saxon
, I get the following Saxon error
when processing the exact same XML file:
Saxon.Api.DynamicError HResult=0x80131500 Message=Output character not available in this encoding (x2211) Source=saxon9he-api StackTrace: at Saxon.Api.XsltTransformer.Run(XmlDestination destination) .....
Note: The entity code ∑
is in the XML file and is for unicode Character “∑” (U+2211).
Question: Why I'm getting the above error on a VSTO
project with the exact same code and files that my WPF
project has (with no such issue there)?
XML file top declaration part:
<?xml version="1.0" encoding="UTF-8" ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:mml="http://www.w3.org/1998/Math/MathML"
xmlns:m="http://schemas.openxmlformats.org/officeDocument/2006/math">
<xsl:output method="xml" encoding="UTF-16" />
....
.....
XSLT file top declaration part:
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:saxon="http://saxon.sf.net/"
xmlns="http://www.w3.org/1998/Math/MathML"
xmlns:om="http://www.openmath.org/OpenMath"
xmlns:m="http://www.w3.org/1998/Math/MathML"
xmlns:h="http://www.w3.org/1999/xhtml"
exclude-result-prefixes="saxon om xs m h"
>
<xsl:import href="pmml2texfrag.xsl"/>
<xsl:output encoding="US-ASCII" method="text" omit-xml-declaration="yes" indent="no"/>
.....
.....
Remark: A Similar issue reported here with some thoughts from Mike Kay (the author of Saxon
). But in my case code works fine on WPF
project and not on a VSTo
project.
There's not really enough information here for us to work out (a) how the two scenarios differ, and (b) why the failure occurs. (For example, you've shown two stylesheet modules with different xsl:output declarations and it's not clear to me how they relate.)
However, if you are indeed using the text output method with encoding us-ascii and are attempting to output the non-ASCII character x2211, then you can certainly expect this failure.
User contributions licensed under CC BY-SA 3.0