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/