From: Gordon Steemson <gsteemso-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
Subject: Flaws in the Pandoc Unicode (OK, UTF-8) handling
Date: Sat, 31 Jan 2015 18:42:55 -0800 (PST) [thread overview]
Message-ID: <97d9c232-cc87-41ca-859b-f7495db3148f@googlegroups.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 2084 bytes --]
I came very close to getting Pandoc to actually do what I mean today.
Unfortunately, when I ran my Pandoc wrapper script (it divides up my
custom-formatted whole-story Markdown files into individual chapters, each
with a prepended metadata block, then calls Pandoc on each individual
chapter) on a different input file, it worked the first couple of times and
then started complaining that a specific well-formed UTF-8 character wasn’t
well-formed (specifically, the CJKV ideograph for girl/woman/female: 女). Pandoc
is the only software I can find that makes this claim about my file, so I
am inclined to believe the file is not at fault — especially since it
worked fine yesterday. I have reinstalled both Haskell and Pandoc, without
effect.
This is not the first time Pandoc has been annoying at me about UTF-8
interpretation; I have found that any attempt to print UTF-8 text to
standard output or standard error from within my custom writer is doomed to
failure. The individual bytes within each UTF-8 encoded character are being
interpreted by some layer within Pandoc as Latin-1 or some similar
single-byte encoding, and then erroneously re-translated into a string of
two or three UTF-8 characters for every single UTF-8 character I try to
output.
Every software setting I have control of is set to UTF-8. Even setting the
locale within Lua with “os.setlocale('en_CA.UTF-8')” doesn’t have any
effect.
I’m completely stumped here. Help!
--
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/97d9c232-cc87-41ca-859b-f7495db3148f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #1.2: Type: text/html, Size: 2581 bytes --]
next reply other threads:[~2015-02-01 2:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-01 2:42 Gordon Steemson [this message]
[not found] ` <97d9c232-cc87-41ca-859b-f7495db3148f-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2015-02-01 6:49 ` John MacFarlane
[not found] ` <20150201064928.GC12964-bi+AKbBUZKbivNSvqvJHCtPlBySK3R6THiGdP5j34PU@public.gmane.org>
2015-02-01 7:43 ` Gordon Steemson
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=97d9c232-cc87-41ca-859b-f7495db3148f@googlegroups.com \
--to=gsteemso-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.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;
as well as URLs for NNTP newsgroup(s).