Hi,
Patrick Cardona wrote:
What file do you mean? The one provided within HelpViewer itself?
Exactly I am testing with the Example files, specifically the HelpViewer
help file, which is correct (or being corrected by me) to be a good
reference.
The base file is actually broken, it is more an experiment, I don't know
how it was generated. It is extremely interesting, but the structure is
wrong. I want to work with Richard if we can generate it better.
Well, if it was standard html, only one directive in the header
document should do what is needed.
What is powered with the existent xlp is the legend within figures. We
should be aware to keep this functionality, maybe related to the parser.
I am unsure, not having tried, where the charset declaration is needed,
per section or per sub-files. Parsing is done in two passes: first the
Structure Handler, then the Text Formatter.
But as said, French stuff comes out fine for me.
Using UTF-8?
using "nothing". As it is things open fine: so the file is consistent
with what the Parser expects.
We could default to UTF-8 for convenience perhaps.
I think this the way modern systems go: we might not only think about
occidental languages.
Probably. Then e.g. use encodings if we can make respect it. I will look
into that.
Oh! you are right. Is there already a matter of checking an existent
help file from the menu command "Info > help" (#?) and if so, what
should be the normalized name of this expected help file? If we
provide L18N, how should be the hierarchy or the naming convention?
I don't know yet. I am still doing the first steps to actually have an
application display a Help file using HelpViewer... most bits were
there, but nobody put them together (or maybe not in the last 10 years).
Small fix in gui was done.
StepSync now has a working Help file. Try! It is just in English, as the
whole app is.
From what I understand (but didn't get it working) Help Files should
follow localisation of resources like the rest of GNUstep resources.
So one can have English, German, French and Italian folders, e. g., and
inside have localized strings, gorm files and also HelpFiles.
I confirm I needed to add many " " to deal with rendering issues.
Spacing is quite complex to render... coalescing in HTML style given the
way.
Once we render correctly, I want to attempt a decent compromise there. I
already tweaked it a little.
Other examples are broken.
Some issues come from GUI, but they are very subtle. I am trying to
compare on mac, but there I need to reimplement things and it behaves
even differently.
Maybe related to css parser engine?
I don't think so: by using the same built-in parser (SVN code is still
wired to GSHTML for GS reference and debugging, but it is a couple of
line shacking to enable it) they should behave the same. So it is in
other details I want to investigate. It is difference in Text Layouting
and there debugging is needed, since the error could be in GNUstep even
if it looks "correct" since the Application was coded for GNUstep and
its bugs
Riccardo
