"Anthony J. Bentley" wrote:
> The below patch causes -mdoc to generate typographic quotes around
> a %T (reference title) instead of straight quotes.
Maybe that should depend on the output format. ``Example'' does IMHO look not
really goot in the text terminal. Many manpages use these quote (
Hi Carsten,
Carsten Kunze writes:
> "Anthony J. Bentley" wrote:
>
> > The below patch causes -mdoc to generate typographic quotes around
> > a %T (reference title) instead of straight quotes.
>
> Maybe that should depend on the output format. ``Example'' does IMHO
> look not really goot in the
"Anthony J. Bentley" wrote:
> I agree that `` '' makes no sense in modern ASCII; even in an xterm they
> look unbalanced. " " would probably be a saner ASCII result for Dq,
> \(lq, \*(Lq, and so forth, but I don't know how complicated a change
> that would be or if there would be any larger impli
> It is generally no problem to differentiate between nroff
> and troff output. I suggest to do this here and to apply
> the patch for typeset output.
I suggest always using \*[Lq] and \*[Rq] without
differentiation here, and instead defining the strings
appropriately for the output device at st
Hi Carsten,
Carsten Kunze writes:
> "Anthony J. Bentley" wrote:
>
> > I agree that `` '' makes no sense in modern ASCII; even in an xterm they
> > look unbalanced. " " would probably be a saner ASCII result for Dq,
> > \(lq, \*(Lq, and so forth, but I don't know how complicated a change
> > that
"Anthony J. Bentley" wrote:
> It's worth noting that groff's refer(1) already uses typographic quotes
> around %T with my -ms documents.
Can you please provide some lines of input for refer/-ms to reproduce this?
Carsten
Hi Carsten,
Carsten Kunze writes:
> "Anthony J. Bentley" wrote:
>
> > It's worth noting that groff's refer(1) already uses typographic quotes
> > around %T with my -ms documents.
>
> Can you please provide some lines of input for refer/-ms to reproduce this?
foo.ms:
.PP
.[
foo
.]
bibliograp
On 06/11/14 12:30, Anthony J. Bentley wrote:
> By ASCII I meant specifically ASCII output. I use UTF-8 terminals and
> the patch was intended to improve how the nroff output looks in that case.
That you use UTF-8 terminals is completely irrelevant; you are confusing
two distinct concepts here -- a
Keith Marshall writes:
> On 06/11/14 12:30, Anthony J. Bentley wrote:
> > By ASCII I meant specifically ASCII output. I use UTF-8 terminals and
> > the patch was intended to improve how the nroff output looks in that case.
>
> That you use UTF-8 terminals is completely irrelevant; you are confusin
>> By ASCII I meant specifically ASCII output. I use UTF-8 terminals
>> and the patch was intended to improve how the nroff output looks in
>> that case.
>
> That you use UTF-8 terminals is completely irrelevant; you are
> confusing two distinct concepts here -- a character encoding
> (UTF-8), an
On 06/11/14 13:57, Werner LEMBERG wrote:
> groff uses different quotes depending on -Tascii or -Tutf8:
Naturally. UTF-8 is a multibyte character encoding; ASCII is strictly
single byte (using only seven bits).
> devascii: lq "
Which is ASCII code 34 (0x22)
> devlatin1: lq "
Again,
Hi Holger,
> .\" I found this for strings
>
> .ds c "
> .ds d "
> .if '\*c'foo' .ds d "bar
> .ie '\*d'bar' .tm *9: true
> .el .tm *9: false
If you want to preserve d's value for later use then you're back to
using a temporary variable to track success so far.
Cheers, Ralph.
Hi,
Carsten mentioned man pages appearing with ``ugly'' doubled single
quotes, as if it were ugly TeX input. ;-) I think some of that might
be down to the man page authors rather than groff's rendering of
correctly written man pages.
$ zgrep '``' /usr/share/man/man1/find.1.gz
exist, it
Keith Marshall writes:
> > Using \*[Lq] and \*[Rq] in Anthony's patch is definitely correct.
>
> I don't disagree. However, Anthony clearly *is* confused, for he claims
> to refer to ASCII output on UTF-8 devices.
I never said that. Maybe you're referring to this paragraph by me:
"By ASCII I me
Ralph Corderoy writes:
> Hi,
>
> Carsten mentioned man pages appearing with ``ugly'' doubled single
> quotes, as if it were ugly TeX input. ;-) I think some of that might
> be down to the man page authors rather than groff's rendering of
> correctly written man pages.
>
> $ zgrep '``' /usr/s
On 06/11/14 17:37, Anthony J. Bentley wrote:
> Should nroff render `` '' as typographical double quotes instead of
> literal ASCII values?
No, definitely not, IMO. It should render them exactly as what the
input says is intended, i.e. two grave accents and two apostrophes. If
a typographic repre
On Wed, Nov 05, 2014 at 11:00:50AM +0100, Werner LEMBERG wrote:
>
> >> groff 1.22.3 has been released.
> >>
> > First, thanks a lot!
> >
> > Should groff compile with gcc version 4.6.3 without warnings?
>
> I guess the answer is no. There are some warnings here and there, and
> I haven't found
> > Should nroff render `` '' as typographical double quotes
> > instead of literal ASCII values?
>
> No, definitely not, IMO. It should render them exactly as
> what the input says is intended, i.e. two grave accents and
> two apostrophes. If a typographic representation is what is
> wanted ..
>
> NB, in the good old days of X11 we used Adobe's ISOLatin1Encoding in
> which those "grave accents" (0x60) *were* typographical left quotes
> (and the apostrophes (0x27) typographical right quotes /
> apostrophes) in both nroff and troff. It's only since Unicode
> screwed up the encoding that
> Well, `` and '' get rendered as typographic double quotes in troff,
This is due to special, manually added, negative kern values for those
characters.
> Because of that I don't know of a way to specify typographic quotes in
> man(7) input aside from ugly escape sequences like \(lq and \(rq.
T
> % automatic double-quotation "support"
This works (unless you need triple-nested (double-single-double)
quotes) because we usually use double-quotes in pairs.
But with single quotes it's a problem in English because the
right single quote doubles as apostrophe.
Still, we can do the same in g
> Well, the Unicode people certainly didn't `screw up' the encoding.
> They simply had to make a decision which of the overloaded meanings of
> the character ` should be retained, and they finally decided to follow
> the available *character* standards like ISO-8859 for round-trip
> compatibility.
Tadziu Hoffmann wrote:
|>> Should nroff render `` '' as typographical double quotes
|>> instead of literal ASCII values?
|>
|> wanted ... well, that is precisely why we have more expressive
|> input notations, such as \(oq, \(cq, \(lq, and \(rq, (for
|
|I agree. Also, it can't do this ea
Hi Gregoire,
Sorry for my late answer I was quite busy these last days.
On Fri, Oct 24 2014 at 01:13:27 AM, GregExp wrote:
> Hi Bertrand,
>
> thank you for your answer. All two ideas are very good, and will make
> the first paragraph more powerful.
>
> I am afraid, I would not found the right
Hi Werner,
Werner LEMBERG wrote on Thu, Nov 06, 2014 at 02:57:50PM +0100:
> groff uses different quotes depending on -Tascii or -Tutf8:
>
> devascii: lq "
> devlatin1: lq "
> devutf8:lq u201C (via `glyphuni.cpp')
This rendering of \[lq] seems a good choice to me and shouldn
> I have registered it in the bug tracker such that it doesn't get
> lost.
Thanks for both!
Werner
Ralph Corderoy wrote (Thu, 06 Nov 2014 16:35:23
+):
> Hi Holger,
>
> > .\" I found this for strings
> >
> > .ds c "
> > .ds d "
> > .if '\*c'foo' .ds d "bar
> > .ie '\*d'bar' .tm *9: true
> > .el .tm *9: false
>
> If you want to preserve d's value for later use then you're back t
27 matches
Mail list logo