Hi Riccardo,
My tests results:
On 2025-11-11 00:23:05 +0100 Riccardo Mottola
<[email protected]> wrote:
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 l
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
I confirm the best choice is the internal Parser.
tests:
Removing previously all the <meta charset="utf-8" /> in all the .xlp
files.
1) without changing defaults
Defaults read org.gnustep.HelpViewer returned:
org.gnustep.HelpViewer 'NSWindow Frame help_window' '341 148 704 858 0
0 1920 1080 '
org.gnustep.HelpViewer NSDefaultOpenDirectory
/home/patrick/SOURCES/agnostep/install/RESOURCES/HELP
So No Parser set?
All seems correct (accented characters in titles and texts, in legends)
-------------
2) Parser Internal set
defaults write org.gnustep.HelpViewer Parser Internal
All seems correct
3) Parser GSHTML set
defaults write org.gnustep.HelpViewer Parser GSHTML
Accented characters were badly rendered.
4) Parser Sloppy
defaults write org.gnustep.HelpViewer Parser Sloppy
Accented characters well interpreted.
Some unexpected double quotes after some titles.
5) Back again to internal parser
Again, all seems correct, without the double quotes issue of Sloppy.
Cheers,
Patrick
--
Patrick Cardona - Pi400 - GNU/Linux aarch64 (Debian 13.1)
Xorg (1:7.7+24) - libcairo2 (1.18.4-1+rpt1 arm64)
Window Maker (0.96.0) - GWorkspace (1.1.0 - 02 2025) - Theme: AGNOSTEP
- MUA: GNUMail (1.4.0)
