Mark Harris <mh-aus...@osj.us> wrote, on 17 Oct 2016:
> On 17 October 2016 at 06:34, Andrew Josey <ajo...@opengroup.org> wrote:
> > We have updated the pdf edition. This addresses the shading issue in the
> > sysconf() manual page,
> > some minor layout issues, and the character used to represent
> > <grave-accent> has also been changed
> > from Unicode LEFT SINGLE QUOTATION MARK to ASCII <grave-accent>.
> > Please note that the page and line numbers are unchanged.
> It appears that <grave-accent> is still represented by U+2018 LEFT SINGLE
> QUOTATION MARK in the new version. For example on line 1277, 3646, 74727,
> 74730, 74738, and many others.
Well, this is most peculiar. When I checked a small test file, copy
and paste from acroread to a uxterm produced an ASCII <grave-accent>.
Applying the same solution to C165 produced the same visual change,
so I automatically assumed it would have had the same effect on copy
I can see now that it did not. What's strange is that the old and
new versions of C165 produce the same UTF-8 characters via copy and
paste, and yet look completely different on the page despite using
the same font.
> Additionally, <apostrophe> is often represented by U+2019 RIGHT SINGLE
> QUOTATION MARK (e.g. line 76378, 76389, 76533, 76658, 76661, 88971, 90440,
> 95836, 111638, 119617, 127964),
We fixed a lot of these during work on the drafts of the 2016 edition.
Unfortunately, it looks like we missed some. The ones you list are
mostly cases where example code has a different macro pair around it
than the usual pair we were looking for.
> <hyphen-minus> is often represented by
> U+2212 MINUS SIGN (e.g. line 1881, 2402, 2567, 2580, 3517, 3594, 6152,
> 6164, 65520), <circumflex> is represented by U+02C6 MODIFIER LETTER
> CIRCUMFLEX ACCENT (e.g. line 1509, 3644, 6105, 6163, 6241, 89508), and
> <tilde> is represented by U+02DC SMALL TILDE (e.g. line 2765, 3677, 88669,
> 89505, 89510, 90551, 90552). (Line number lists are incomplete.) This
> means that code fragments copied from the PDF will often not work.
Where these are in normal text, I believe it is intentional. Where they
are in monospace font (particularly if it's example code), we should
consider fixing them.
Whether we can fix any of these problems now and replace C165 yet
again, or if they will have to wait until the next revision, is a
matter for Andrew and Cathy to decide.
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England