From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [PATCH] Table continuation strings Date: Sun, 22 Dec 2013 09:20:57 +0100 Message-ID: <878uvdjnyu.fsf@gmail.com> References: <87ppqn9i9j.fsf@gmail.com> <87lhzec2sh.wl@dns1.atmark-techno.com> <87k3eyk200.fsf@gmail.com> <87iouhc1bi.wl@dns1.atmark-techno.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45747) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VueHE-000742-RW for emacs-orgmode@gnu.org; Sun, 22 Dec 2013 03:20:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VueH9-00060a-5C for emacs-orgmode@gnu.org; Sun, 22 Dec 2013 03:20:44 -0500 Received: from mail-wg0-x232.google.com ([2a00:1450:400c:c00::232]:60304) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VueH8-00060T-FB for emacs-orgmode@gnu.org; Sun, 22 Dec 2013 03:20:39 -0500 Received: by mail-wg0-f50.google.com with SMTP id a1so3980454wgh.5 for ; Sun, 22 Dec 2013 00:20:37 -0800 (PST) In-Reply-To: <87iouhc1bi.wl@dns1.atmark-techno.com> (Yasushi SHOJI's message of "Sun, 22 Dec 2013 06:59:45 +0900") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Yasushi SHOJI Cc: emacs-orgmode@gnu.org Hello, Yasushi SHOJI 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