Essential viewer v3 : no output encoding in xsl files

[jmk]

Under linux, the following will add a latin1 encoding to each xsl files when run from the webapp root:

Code: Select all

find . -name \*.xsl -exec sed -i -e 's/xsl:output/xsl:output encoding="ISO-8859-1"/' {} \;

J.-M.

[neil.walsh]

Thanks for the tip. All the xsl files in Essential Viewer have UTF-8 encoding. Is this proving a problem for any reason?

[jmk]

This is not a problem with the encoding of ths xsl files but a problem with the encoding of the html output.

As I understand the xsl standard there is no causal relation for file encoding between xsl files and their output.

J.-M.

[neil.walsh]

Apologies, I wasn't quite clear enough.

The encoding for the output is set in the file called ev3_common_head_content.xsl within the common folder.

The following line sets the encoding for all the html output

Code: Select all

<meta http-equiv="content-type" content="text/html; charset=UTF-8" />

Are you having problems with encoding in anyway? If so, we'd love to hear your experiences.

Thanks

Neil

[neil.walsh]

The Protege team have written a great page which explains more about file encoding within Protege and their choice of UTF-8.

http://protege.stanford.edu/doc/file_encodings.html

Is there any reason you're looking at the ISO-8859-1 standard?

[jmk]

Mmm, IMHO, the meta-tag you gave does not imply that the xml output will be in utf-8, It merely declares that the resulting html document should be in utf-8 at the html level. I think also that the xsl output encoding is, by default, implementation defined.

I had some encoding problem in my browser (probably because of my tomcat environment) and found convenient to use the iso-8859-1 encoding . Maybe because it saves some bytes in my underpowered, memory hogged machine.

I didn't imply that Latin-1 is the encoding to use. It just appears to work in my conf but utf-8 is a good choice .

Encodings may sometimes be such a mess ... you don't know how lucky you are, you, as diacriticless anglo-saxon people

[jonathan.carter]

Thanks very much for your postings - they've really helped us resolve this one.

The fix for the character encoding will be included in the next minor release of Essential Architecture Manager.

Until then, we have uploaded a new version of the Essential Viewer Engine to the Share area. Instructions for how to download and install the new version of the Engine are included on that page but do let us know if you have any problems.

Jonathan

[peter.fuzi]

Mates,

I met the same problem as an architect in Hungary (CE). Our alphabet needs use of IEC-8859-2 table.
A while ago I found Jon's hint & patch above, installed it, and Essential_Viewer started to display my model info in perfect Hungarian !

Your patching effort and support is highly appreciated!
Thanks with regards, Peter

[jonathan.carter]

Thanks Peter!

We'll get that patch into the next minor release of the software very soon.
Great to hear that it resolved your issue!

Jonathan

[peter.fuzi]

Jonathan, my cheer came early. The resolution was a comet phenomenon: came fast, went fast! In fact my configuration (standalon Windows based) has still suffered a weak setup. As I understand, UTF-8 is suitable to accomodate Hungarian language characters too. Unfortunately I have not had enough experience neither with character codes, nor with Tomcat.

I report as soon as I found the proper setup.
Thanks, Peter

[jonathan.carter]

Hi Peter,

Have you been able to resolve the UTF-8 setup?

Keep us posted - and let us know if there are any things we need to add to the Viewer Framework

Thanks

Jonathan