Rick Frankel <r...@rickster.com> writes: > On 2014-03-17 23:36, Rasmus wrote: > When you refer above to "utf-8 entities", do you mean the named html > entities (e.g., <) or the actual utf-8 encoded characters?
The latter. Do M-x describe-char on such an character. Emacs will tell you the code points. My conjecture is therefore that one could write a script that would translate html values to these weird hex string or codepoints. It would create more ugly source output, but perhaps better for XHTML. Personally, I don't care about XHTML as I have little intuition as to when to use. . . > I believe the named entities are encoding independent, while including > encoded characters in html output is fine -- although making sure the > page is served with the correct character encoding is another issue > entirely. Not what I meant. I'm only addressing your concern about &HUMAN-READABLE-NAME; vs %HEX-VALUE;. > As to using a more extensive set of named entities, as i said above, > the problem is that the xhtml flavors don't support them, and I don't > see any advantage in making the exporter handle character encoding > differently based on ouput doctype. Definitely not. Why I ask if there's a point in changing nice entities to ugly entities for the sake of not getting them in XHTML-encoded documents. > As Nicolas would point out, you can always use a filter to map all the > entities in the output. With ox-latex.el we for instance don't include entities that are not supported by the default package alist. A similar concern could be at play here. –Rasmus -- El Rey ha muerto. ¡Larga vida al Rey!
