Re: Two questions about HelpViewer

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