Re: [O] [PATCH] Table continuation strings

[Nicolas Goaziou]

Hello,

Yasushi SHOJI <address@hidden> writes:

> Ah, OK.  Those coding keys are for the back-ends to select proper
> strings, not for the string encoding.

This is also related to string encoding. You will get garbage if you
insert a string containing characters outside the encoding you use to
save the file, won't you?

> Then, is there any restriction with HTML back-ends? Why does it need
> numeric character reference instead of just plain characters, if the
> coding system is not a concern?

See above. You may want to save your html file in a different encoding
than UTF-8. IIUC, numeric character reference are more generic.

> Correct me if I'm wrong.  My understainding is as follows: All
> translation strings is in `emacs-internal' coding system, since it is
> defined in .el.  A org file ready to be exported has a coding system
> specific to the buffer, ie. utf-8, iso-latin-1, euc-jp, etc.

Correct.

> Org export back-ends get a strings for the back-ends from the
> translation table when appropriate.  At that time Emacs converts the
> strings encoding system to match the buffer encoding system (or does
> Emacs convert all encoding when it writes to file?).

The latter. The output in concatenated into a single string, which is
then inserted in the target buffer (and saved to a file, if needed).

> Back-ends uses `org-export-coding-system' if set, otherwise use the
> current buffer coding system.

Some back-ends also use their own variable (e.g.
`org-html-coding-system').

> If my understanding is ok, all entries of Japanese translation should
> have :default instead of :utf-8.

:default instead of :utf-8 means Org will use these translations also
for LaTeX, HTML and ASCII export. If you think that is correct, then we
can switch to :default, indeed.


Regards,

-- 
Nicolas Goaziou