Re: proposal for html manual cross links

> > Here is an updated version of the html cross manual references proposal.
> 
> I hope that I understand this correctly: this proposal describes
> transformation only for cross-references (as opposed for transforming
> Texinfo into HTML in general).

That's right.

> First of all: why do you say above ``cross manual references''?
> Aren't we going to produce references to the same manual in a way
> that is identical to cross-manual references?

It could. But it is not required in order to comply with that proposal.
The idea is that the interface to outside manuals should be as stable as
possible and anticipate further advances in the html standards and in the 
texinfo language and implementations. But within the manual you can do 
anything you want.

I did that proposal primarily because I develop texi2html and I wanted
to be able to do cross references to and from manuals generated by 
makeinfo. I implemented the scheme allready present in makeinfo
in texi2html, but I found some shortcomings with that scheme:

- there are characters other than [A-Za-z_-] in target names, although
  in xhtml only those characters are allowed in id= or a= attributes.
- @-commands in nodes are not handled very nicely. 
- Some nodes aren't disambiguated. For example:
     @node %node
     @node -node

> Please say "Unicode character" instead of "utf8 character" throughout
> this document.  0x2217 is the Unicode codepoint, while its UTF8
> encoding is something very different.  "U+2217" is the accepted
> shorthand for "Unicode codepoint hex 2217", so perhaps let's use that.

Right.

> Why do you prefer the non-Latin1 alternative unconditionally?  Isn't
> it better to let this be driven by @documentencoding?

The cross manual references should be (in my opinion) independant of the
@documentencoding, otherwise whenever the @documentencoding changes the
references become wrong (the document being viewed as a source of cross
references or a target). Thus an unconditionnal choice has to be maid 
whatever the @documentencoding is. If you prefer the reverse (use the 
latin-1 for the characters appearing twice), it is not a problem, but
a choice has to be made.

> Some characters are not allowed in file names on certain filesystems.
> For example, `|', `>' and `?' are not allowed on Windows.  SPACE
> sounds like not a good idea, either.  (But see below, where I comment
> about 7-bit ASCII.)

These 7 bit ascii characters are further transformed below. Thus
| -> _007c
and so on for other 7-bit ascii characters.

> It is not clear whether these rules are applied recursively or not.

Yes, recursively (except for _ -> _005f)

> For example, am I to understand that multiple spaces are transformed
> like this:
> 
>    SPACE SPACE SPACE -> SPACE -> _0020

Almost like that escept that there is a special rule for SPACEs, they 
are transformed into -. Thus we have

SPACE SPACE SPACE -> SPACE -> -

> ?  In other words, will we have a file name with spaces in it or not?

At that point there is nothing like a filename. I am still telling how to
expand node names. But in the end this will lead to node name and target 
names, and there will be only [A-Za-z-_] in these names (thus, no space).

> "ascii 7 bit" is a bit vague; how about mentioning the precise range
> of ASCII codepoints of characters that are transformed into _00xx
> notation?

It is in the end of my mail, the second perl hash.
 
> It is not clear what to do with 8-bit single-byte characters, in case
> the Texinfo source includes them.  If you mean that we should convert
> them to Unicode, we should specify how.

You are totally right. This part is missing. And I don't feel very 
comfortable with that. The tricky situation appears when a manual is 
written in a given 8-bit documentencoding, and another manual, written
in another 8-bit documentencoding wants to refer to the first manual.
 
> Why not do what we do in the current code?  Leaving nodes unreachable
> is not a good idea, IMHO.

I fully agree, but the current code is worse. I don't think there is a case 
where the current code better disambiguate than the proposal. If it is the 
case, the proposal should be changed.

Pat
_______________________________________________
Texinfo home page: http://www.gnu.org/software/texinfo/
[email protected]
http://ff0.org/mailman/listinfo/texinfo-pretest