public inbox for linux-kbuild@vger.kernel.org
 help / color / mirror / Atom feed
From: Ben Hutchings <ben@decadent.org.uk>
To: Jonathan Corbet <corbet@lwn.net>
Cc: "Jérémy Bobbio" <lunar@debian.org>,
	reproducible-builds@lists.alioth.debian.org,
	linux-doc@vger.kernel.org, "Randy Dunlap" <rdunlap@infradead.org>,
	"Michal Marek" <mmarek@suse.com>,
	linux-kbuild <linux-kbuild@vger.kernel.org>
Subject: Re: [PATCH 2/2] DocBook: Use a fixed encoding for output
Date: Mon, 14 Sep 2015 01:32:50 +0100	[thread overview]
Message-ID: <1442190770.2298.31.camel@decadent.org.uk> (raw)
In-Reply-To: <20150911133059.77455c16@lwn.net>

On Fri, 2015-09-11 at 13:30 -0600, Jonathan Corbet wrote:
> On Tue, 01 Sep 2015 23:49:19 +0100
> Ben Hutchings <ben@decadent.org.uk> wrote:
> 
> > Currently the encoding of documents generated by DocBook depends on
> > the current locale.  Make the output reproducible independently of
> > the locale, by setting the encoding to UTF-8 (LC_CTYPE=C.UTF-8) by
> > preference, or ASCII (LC_CTYPE=C) as a fallback.
> 
> I guess I have to ask, though: doesn't it seem that having the docs
> produced according to the current locale is the Right Thing to do?  Users
> have their locale set as it is for a reason, it seems like the production
> of textual documents should respect their choice.
> 
> Am I missing something here?

Yes - the locale's character encoding applies to plain text, but rich
text formats can have a locale-independent encoding which the viewer
will automatically to the current locale's encoding.

For HTML, the document encoding can be explicit in the document header
(and is, in this case).

Manual pages were already consistently encoded in UTF-8, as this is the
default behaviour of DocBook-XSL (and is what man-db prefers as input).

PDF and Postscript documents have arbitrary and explicit mappings from
character numbers (or names) to glyphs, and PDF documents normally have
a mapping from glyphs back to Unicode code points to support searching
and copying text.

Ben.


  parent reply	other threads:[~2015-09-14  0:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-01 22:47 [PATCH 0/2] More reproducible document builds Ben Hutchings
2015-09-01 22:49 ` [PATCH 2/2] DocBook: Use a fixed encoding for output Ben Hutchings
2015-09-11 19:30   ` Jonathan Corbet
2015-09-11 21:40     ` [Reproducible-builds] " Daniel Kahn Gillmor
2015-09-12 20:06       ` Jonathan Corbet
2015-09-14  0:32     ` Ben Hutchings [this message]
2015-09-18 16:30       ` Jonathan Corbet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1442190770.2298.31.camel@decadent.org.uk \
    --to=ben@decadent.org.uk \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=lunar@debian.org \
    --cc=mmarek@suse.com \
    --cc=rdunlap@infradead.org \
    --cc=reproducible-builds@lists.alioth.debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox