From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: [org-e-latex] Coding System Date: Fri, 23 Nov 2012 07:34:37 +0100 Message-ID: <87mwy8969u.fsf@Rainer.invalid> References: <87boet5vuc.fsf@Rainer.invalid> <87pq35d9yb.fsf@gmail.com> <87r4nlfrb5.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:38581) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tbmqn-0001wH-GV for emacs-orgmode@gnu.org; Fri, 23 Nov 2012 01:34:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tbmqk-00055G-5E for emacs-orgmode@gnu.org; Fri, 23 Nov 2012 01:34:57 -0500 Received: from plane.gmane.org ([80.91.229.3]:35906) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tbmqj-000550-V5 for emacs-orgmode@gnu.org; Fri, 23 Nov 2012 01:34:54 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Tbmqs-00080m-8j for emacs-orgmode@gnu.org; Fri, 23 Nov 2012 07:35:02 +0100 Received: from pd9eb26cb.dip.t-dialin.net ([217.235.38.203]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 23 Nov 2012 07:35:02 +0100 Received: from Stromeko by pd9eb26cb.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 23 Nov 2012 07:35:02 +0100 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: emacs-orgmode@gnu.org Thomas S. Dye writes: > I don't follow the details of this discussion, but I wonder how > important AUTO really is? I'm afraid I can't follow you… AFAIK, specifying "AUTO" in the LaTeX header is supposed to be replaced by whatever the coding system of the LaTeX buffer happens to be when it gets saved. (I've never used it, so it might work differently.) > It seems to me that a sweet setup uses utf-8 in the buffer but exports > latin-1 to LaTeX through use of entities and filters (with the new > exporter). This can yield a buffer display that isn't complicated by > all the LaTeX machinery, and export something that is maximally > compatible in the LaTeX world. It is nice on the eyes and avoids > encoding incompatibilities on the back-end. That is not what I was talking about, however useful it might be. I have already defined the input encoding "utf8" in my LaTeX header and want to ensure that the buffer gets saved in that format. As an extension, if I specify any other encoding for LaTeX, the buffer should be saved in a matching encoding, independently of the encoding that the org buffer had. If that's a "downgrade", i.e. not all characters are encodable in that new system, then what you describe above might become necessary. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables