Otfried Cheong wrote:

> I had always wanted to fix the charset issue.  Ideally, Hyperlatex
> should automatically put in ASCII if that's all that's being used, and
> otherwise complain if the user didn't specify the charset.

By mistake I replied to Tom's query sending my answer
to his private address. Here are the main points of
that private letter.

Usually I enforce, defining a \htmlcharset command,
that my HyperLatex-generated html documents contain
a meta tag with Windows cp1250 charset. With version
2.8 I encounterd a problem that everything in my
document but the top panels was intepreted to be
in that charset while the panels were in UTF-8.
For example, when I put Spis tre/sci (Polish for
Table of contents) as a panel button then it was
badly interpreted. The words Spis tre/sci are in
cp1250 in the input and HyperLatex sends them
unchanged to the output. It's the

  <?xml version="1.0" encoding="UTF-8"?>

line, that makes a browser to misinteprete
the letter /s (sacute) and show it badly.

There are two places in hyperlatex.el where UTF-8 is
mentioned explicitly. It seems that when we replace these
two places with references to a new hyperlatex-xml-charset
variable, like in this:

  (hyperlatex-gen
    (concat "?xml version=\"1.0\" encoding=\"" hyperlatex-xml-charset
         "\"?")
   ...

then we we gain enough flexibility for HyperLatex
in respect to various encodings. I am not sure, though...

> When I implemented this in 1993, <a name="id4"></a> simply didn't work
> on common browsers (Mosaic and Netscape at the time).  If I remember
> right, the HTML specification also required there to be text inside the
> element. (In HTML, a label marks an object, not a position.)  One would
> need to check the current HTML specification to see whether it's legal
> to have an empty tag - just because Firefox does it right doesn't mean
> Hyperlatex should create illegal HTML  (but hopefully it's alright now).

There is a note in

  http://www.w3.org/TR/REC-html40/struct/links.html#h-12.2

stating that browsers should accept empty anchors.
As some of them do not why not to make the generation
of empty anchors an option? I know the group of readers of
my documents (help files of a sort) and I know which
browsers this group is using. Thus I can well judge
whether empty anchors are acceptable.

Best Regards
Rysiek



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Hyperlatex-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hyperlatex-users

Reply via email to