> > > -//{ "\\-", "2212" },
> > > + { "\\-", "2212" },
> >
> > This change doesn't make sense. It's not possible to use a
> > backslash within \[...]. Consequently, glyph names which start
> > with a backslash can't be used as composites.
>
> The patch part 14 uses the glyph_name_to_unicode() fu
On 23-Feb-06 Robert Marks wrote:
> Does any of the fonts in the standard distributions of groff contain
> characters depicting the standard male and female symbols?
> (The circle with the oblique arrow above, and the circle with the cross
> below.)
> Inquiring minds would like to know.
No -- not i
I'm trying to make some macros that will build up the SEE ALSO list in a man
page so I can do
.SH SEE ALSO
.SA foo
.SA bar
.SA blech
.SH SOMETHING_ELSE
and get
SEE ALSO
foo, bar, blech
SOMETHING_ELSE
The approach I took was to try and rename the .SH macro to som
> I use the lilypond music typesetting system to engrave my scores,
> [...]
Interesting. If you say `my scores', do you mean that you are
actually a composer too?
> but I nearly always start off with one of the graphical front ends
> to lily to generate a file I can work with. It's a tremendou
Werner LEMBERG wrote:
> > - make glyphuni.cpp consistent with devhtml and devutf8. groff
> > currently already converts "\-" to U+2212 in the output; this
> > change to glyphuni.cpp doesn't change the behaviour, unless
> > composed characters will be used.
> >
> > -//{ "\\-", "2212" }
Heinz-J?rgen Oertel <[EMAIL PROTECTED]> wrote:
please try
groff-wiki.info
or
www.groff-wiki.info
Heinz
Good beginning!
- Manas Laha
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
> How would I pass arbitrary ps parameters to an included ps routine?
>
> E.g.
>
> .something 50 (hello) 100
You probably want something like this:
.de END
..
.
.de something
. de something-aux END
ps: exec \\$*
. END
\Y[something-aux]
..
.
.something 50 (hello)
(Sorry Peter, I meant to send that to the group...)
When I was a youngster (yes!), device independence
and pre- and post-processors were good ideas and necessary. I
wonder whether it still is the case.
For me: definitely yes.
I concur.
Yes. You have PS/PDF and plain text (usually for man
> > Well, the .devicem macro will be exactly the same as \Y. To
> > create similar code with grops you have to use the `ps: def ...'
> > grops command to define a PS macro which is then executed with
> > `ps: exec' -- I'm sure you know that :-)
>
> I wouldn't do that. I have thousands of lines of
> It seems, looking at the headers of recent mails to the list, that
> postings to the groff list are being delayed at lists.gnu.org by
> 6-12 hours, typically over 9 hours.
Apparently a problem with the list server on gnu.org...
> Is this (as I hope) a temporary phenomenon?
I hope so. All gnu.
> - make glyphuni.cpp consistent with devhtml and devutf8. groff
> currently already converts "\-" to U+2212 in the output; this
> change to glyphuni.cpp doesn't change the behaviour, unless
> composed characters will be used.
>
> -//{ "\\-", "2212" },
> + { "\\-", "2212" },
This c
What is the real state of the troff land? What are the other
players beyond groff?
Some people still use the now defunct troff version of QuadSoft (many
syntactical extensions implemented in groff resemble its format), many
use Sun's troff (based on AT&T), and others rely on Plane 9's troff
(
> > OK. Additionally, I'll completely remove the remaining traces of an
> > `shc' glyph.
>
> Oops, maybe we will want to use it for hyphenation in the HTML
> browser? I mean, groff with devutf8 device could generate HTML
> containing elements, leaving the line breaking and
> hyphenation to the
> > Under normal circumstances, `shc' is never a glyph in groff.
> [...]
>
> So it should make sense to align glyphuni.cpp to what all devices do.
> I propose this patch.
>
> - { "shc", "00AD" },
> +// The glyph \[shc] is not useful for typographic purposes.
> +// U+00AD is meaningful only in the
> > Currently, there is a single non-spacing glyph used in groff
> > (`slashnot' in devdvi; the other non-spacing glyphs from the
> > various DVI fonts have no names), and this has to be placed before
> > the base character. Additionally, it isn't a valid Unicode
> > character so there is no conf
> I will add the `shc' entry back to grohtml.
After some thinking I've now decided not to do this. Reason is that
we need a different mechanism for proper `' support. Currently,
groff emits a soft hyphen glyph only at line ends: With other words,
`' (or rather `') has never been emitted for
> Regarding the implementation of the \Y equivalent perhaps it is
> useful to have a look at how SGI-troff-Adobe-ps handled the
> situation.
Well, the .devicem macro will be exactly the same as \Y. To create
similar code with grops you have to use the `ps: def ...' grops
command to define a PS ma
> But there are already 418 characters with non-trivial combining classes
> listed in
>
> http://ftp.unicode.org/Public/5.0.0/ucd/extracted/DerivedCombiningClass-5.0.0d10.txt
>
> Will the startup time penalty to register all these one by one be
> acceptable?
I think so. Compare this to LaTeX
Werner LEMBERG wrote:
> > > Under normal circumstances, `shc' is never a glyph in groff.
>
> OK. Additionally, I'll completely remove the remaining traces of an
> `shc' glyph.
Oops, maybe we will want to use it for hyphenation in the HTML browser?
I mean, groff with devutf8 device could generate
Does any of the fonts in the standard distributions of groff contain
characters depicting the standard male and female symbols?
(The circle with the oblique arrow above, and the circle with the cross
below.)
Inquiring minds would like to know.
Thanks
--
Robert MARKS, Australian Graduate School o
Hello Werner,
> > So I imagine that noone will object if troff combines
> >
> > x\[u0302]\[u0301]
> > into
> > \[u0078_0302_0301]
>
> I think this is OK. Currently, there is a single non-spacing glyph
> used in groff (`slashnot' in devdvi; the other non-spacing glyphs fr
On 23/02/2006, at 6:33 PM, Werner LEMBERG wrote:
Regarding the implementation of the \Y equivalent perhaps it is
useful to have a look at how SGI-troff-Adobe-ps handled the
situation.
Well, the .devicem macro will be exactly the same as \Y. To create
similar code with grops you have to use t
> > +++ groff-20060217/src/libs/libgroff/glyphuni.cpp
> > @@ -398,7 +398,8 @@
> >{ "mi", "2212" },
> >{ "-+", "2213" },
> >{ "**", "2217" },
> > -//{ "sqrt", "221A" },
> > + // \[sqrt] and \(sr are the same.
> > + { "sqrt", "221A" },
> >{ "sr", "221A" },
> >{ "pt", "221D" },
>
> There are certainly cases where one needs to call one or more of the
> pre-processors in the "troff" phase of the pipeline, and even
> interpose a "pre-post-processor between the ditroff output of troff
> and the final post-processor.
For the latter case there is the `.output' request which ins
Michail Vidiassov wrote:
> "Fine", "wrong" - may be the answer is "it depends"
> (on the availability of the precomposed glyph in the font)?
No, it shouldn't depend on that. troff does an early pass where is
constructs a precomposed glyph from the base character and the combining
characters, and s
25 matches
Mail list logo
