If I open a XML-file with the following first line:
<?xml version="1.0" encoding="windows-1252"?>
I get an error:
Using local encoding because TDAX-004.105.60.01.02_05.12.2006_11.33.34.xml is neither valid UTF-8 nor well-formed XML: Error at line 1, column 31: unknown encoding
Why are there only "UTF-8, UTF-16, UTF-16LE, UTF-16BE, ISO-8859-1, US-ASCII" allowed?
Because I can't validate and/or check for wellformness.
The other problem is the "pretty-print" function.
I can't use them, because everytime I get an error. Told me, that an entity is not found...
But I checked the file with XML-Spy, and I found no errors. (File is valide, wellformed and with XML-Spy also "pretty-printable").
So, how work the funktion? I think the xmlcopyeditor uses an other way to pretty-print.
Best regards,
Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thomas, thanks for getting in touch. The program's parser can read a fair number of encodings, but it seems that Windoes-1252 is not one of them.
XMLSpy, being a Windows-only application, uses MSXML to load files; the problem is that MSXML accepts a wider range of Windows-specific encodings than libxml (which started out as the Gnome XML parser on Linux).
I should stress that you are not limited to utf8, utf16, utf16le, utf16be, iso-8859-1 and us-ascii: these are the encodings supported by the program's core parser, Expat. To cater for other encodings, the program tries to open the document with libxml if the initial parse fails with an unknown encoding error. The problem only becomes apparent to the user if libxml cannot read the document either.
I'm intrigued by the pretty-print error. If that is possible, would you mind sending me the document so I can look into this? (My email is gnschmidt at users dot sourceforge dot net.) One possibility is that you need to permit the parser to access remote DTDs – this is disabled by default. You can select this options under Tools>Options...>General.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thanks for your answer.
I have select the option for remote DTDs correct, but the problem is still existing.
I will send you an example document next time.
Is there a chance for a solution to work with documents with special windows-encoding?
I think nor really, isnt it?
(I know, it would be better to use an other encoding, but the FrameMaker does not understand any other...)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One possibility is to use the large document mode (File>Open Large Document): this will default to your local encoding, which may well be Windows-1252 in your case. Once the document is open, you'll be able to switch to UTF-8 (or one of the other built-in encodings) and then you'd be on your way.
Another possible solution would be an equivalent ISO encoding: have you tried ISO-8859 or (failing that) ISO 8859-15? I don't expect OS parsers will be in a hurry to implement Windows-only code pages.
Of course it's possible to provide support for custom encodings, but I am reluctant to introduce further complexity into the open/save mechanism: unlike text editors, XML editors need to pass through a parsing stage before opening the document, so editors tend to depend on their chosen parsers for encoding support.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If I open a XML-file with the following first line:
<?xml version="1.0" encoding="windows-1252"?>
I get an error:
Using local encoding because TDAX-004.105.60.01.02_05.12.2006_11.33.34.xml is neither valid UTF-8 nor well-formed XML: Error at line 1, column 31: unknown encoding
Why are there only "UTF-8, UTF-16, UTF-16LE, UTF-16BE, ISO-8859-1, US-ASCII" allowed?
Because I can't validate and/or check for wellformness.
The other problem is the "pretty-print" function.
I can't use them, because everytime I get an error. Told me, that an entity is not found...
But I checked the file with XML-Spy, and I found no errors. (File is valide, wellformed and with XML-Spy also "pretty-printable").
So, how work the funktion? I think the xmlcopyeditor uses an other way to pretty-print.
Best regards,
Thomas
Thomas, thanks for getting in touch. The program's parser can read a fair number of encodings, but it seems that Windoes-1252 is not one of them.
XMLSpy, being a Windows-only application, uses MSXML to load files; the problem is that MSXML accepts a wider range of Windows-specific encodings than libxml (which started out as the Gnome XML parser on Linux).
I should stress that you are not limited to utf8, utf16, utf16le, utf16be, iso-8859-1 and us-ascii: these are the encodings supported by the program's core parser, Expat. To cater for other encodings, the program tries to open the document with libxml if the initial parse fails with an unknown encoding error. The problem only becomes apparent to the user if libxml cannot read the document either.
I'm intrigued by the pretty-print error. If that is possible, would you mind sending me the document so I can look into this? (My email is gnschmidt at users dot sourceforge dot net.) One possibility is that you need to permit the parser to access remote DTDs – this is disabled by default. You can select this options under Tools>Options...>General.
Hi,
thanks for your answer.
I have select the option for remote DTDs correct, but the problem is still existing.
I will send you an example document next time.
Is there a chance for a solution to work with documents with special windows-encoding?
I think nor really, isnt it?
(I know, it would be better to use an other encoding, but the FrameMaker does not understand any other...)
One possibility is to use the large document mode (File>Open Large Document): this will default to your local encoding, which may well be Windows-1252 in your case. Once the document is open, you'll be able to switch to UTF-8 (or one of the other built-in encodings) and then you'd be on your way.
Another possible solution would be an equivalent ISO encoding: have you tried ISO-8859 or (failing that) ISO 8859-15? I don't expect OS parsers will be in a hurry to implement Windows-only code pages.
Of course it's possible to provide support for custom encodings, but I am reluctant to introduce further complexity into the open/save mechanism: unlike text editors, XML editors need to pass through a parsing stage before opening the document, so editors tend to depend on their chosen parsers for encoding support.