Hi,
since I am working extensively on HelpViewer, it is not easy as that,
but thank you for stimulating me looking at the issue more.
I added character encoding recognition support in HadlerStructureXLP. It
will try to parse a like in the form:
<?xml version="1.0" encoding="utf-8"?>
and assume UTF-8 by default, in XML style. This will need to be
documented well.
Patrick Cardona wrote:
It seems finally that writing the meta: <meta charset="utf-8" /> once
at the very begining of each xlp file is enough to avoid the issue.
Doing that, the workaround is lighter.
I have brought the internal Parser up to spec enough that it can display
the example files without major errors and with no crashes.
For testing purposes, you can switch different parsers.
defaults write org.gnustep.HelpViewer Parser Internal
defaults write org.gnustep.HelpViewer Parser GSHTML
defaults write org.gnustep.HelpViewer Parser Sloppy
built-in parser resuscitated vs. libxml2 based GSHTML parser and GSXML
in Sloppy mode.
Since we are not pure XML nor HTML the results are interesting, however
the Internal parser seems now quite usable with some care in writing the
xlp.
The issue is that the whole chain may not be UTF-8 clean and that the
XML parser is called twice, first from HandlerStructureXLP then from
TextFormatterXLP.
GSHTML assumes Latin 1 if not specified.
I changed the pipeline to go through UTF-8 if not specified and if
specified, to convert to UTF-8. However GSHTML might choke because it
either respect the existing character encoding.
I probably need to remove or even rewrite the encoding line.
However, in the long run I want to retain the internal Parser which
gives us freedom and also allow the use of the mixed XML-HTML style the
format is based on.
You can play around with SVN.
Riccardo
