[bug #64592] [troff] registers .m and .M contain no initial value

[Deri James]

Follow-up Comment #6, bug #64592 (project groff):

[comment #5 comment #5:]
> Is the problem that registers .m and .M don't behave like other registers
(containing the default values), or that the roff language offers no way to
retrieve these defaults?

See comment #3 which mentions two registers which reflect the default value.
The problem is that precise initial glyph and fill colours are probably only
relavent for X, dvi, ps and pdf. For tty and html initial colours are chosen
by the console/browser.

My proposed "fix" for this bug is to add:-

.gcolor black
.fcolor black

To the startup tmac for the 4 drivers mentioned above, e.g. pdf.tmac, and
document in gropdf.1 that the default colours are black. Which means that if a
user interogates \n[.m] they will find the value "black" rather than an
unhelpful null value.

While we are on the subject of colour, a little rant:-



For pdfs and probably postscript there are two drawing modes, stroke and fill.
For graphical objects, using \D commands \m is the stroke colour and \M is the
fill colour, but, for text \m is the fill colour, since the paths described by
font glyphs are always filled, not stroked. If glyphs were stroked rather than
filled you get hollow outlines of the letters. Of course, with pdf, you can
specify whether you want text glyphs to be filled or stroked or both, but the
default is filled only. This means I have to swap the meaning of \m depending
on whether gropdf is dealing with graphics or text.

This really has nothing to do with this bug, its really just a note to myself
that if I introduce a pdf extension to control fill/stroking glyphs, I need to
unswap the meaning of \m if the user asks  for stroking!!


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64592>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/