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

[Dave]

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

[comment #6 comment #6:]
> See comment #3 which mentions two registers which reflect the default
value.

I apologize for being dense, but I don't see in comment #3 (or any other
comments) what registers contain the default colors.  In comment #1, Branden
mentions the color _named_ "default" but also says "I don't know that we have
access via the _roff_ language to what that default is."  Comment #3 mentions
two _other_ registers that are initially populated with default values (.fn
for font and .s for type size), hence my trying to clarify whether the
objection this bug is raising is (1) that .m and .M are "odd men out" in not
being populated with default values, or (2) that no other mechanism exists to
retrieve the default colors.

I make the distinction because (2) can be solved in a way that doesn't break
compatibility.  (I don't know if this particular aspect of compatibility is
important to anyone.  But some users might use the existing behavior, for
example to test whether any colors changes have yet been made in a document.) 
But your example in the original submission might be trying to show that the
.m/.M behavior also complicates certain aspects of color handling, meaning (1)
is the root problem.


___

Reply to this item at:

  

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

[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:

  

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

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

[Dave]

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

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?


___

Reply to this item at:

  

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

Re: [MOM[ unexpected behaviour when using blockquotes with two columns

[Peter Schaffter]

On Thu, Nov 16, 2023, hbeze...@kliksafe.nl wrote:
> Dear Peter,
> 
> Thanks for the fast reply. It worked!
> Two small remarks:
> 1. The current release link redirects to the older version:  https://
> www.schaffter.ca/mom/mom-2.6.tar.gz

It's working now.  The page was slow to update, that's all.

> 2. In groff_mom there's a link to the local html manual (/usr/share/doc/
> groff-1.23.0/html/mom/toc.html), but most recent version of Groff on Arch 
> Linux
> doesn't include the html pages, at least not where the points to.

Branden?  Anyone?

-- 
Peter Schaffter
https://www.schaffter.ca

Re: [MOM[ unexpected behaviour when using blockquotes with two columns

[hbeze...@kliksafe.nl]

Dear Peter,

Thanks for the fast reply. It worked!

Two small remarks:

1. The current release link redirects to the older version: 
https://www.schaffter.ca/mom/mom-2.6.tar.gz

2. In groff_mom there's a link to the local html manual 
(/usr/share/doc/groff-1.23.0/html/mom/toc.html), but most recent version of 
Groff on Arch Linux doesn't

include the html pages, at least not where the points to.

Kind regards,

Hans

> 
> Op ,Thu Nov 16 2023 06:25:17 GMT+0100 (Central European Standard Time),
> schreef Peter Schaffter : -- Oorspronkelijk
> bericht --
> 
> On Wed, Nov 15, 2023, hbeze...@kliksafe.nl via wrote:
> > I'm preparing an
> article using mom with a two column layout.  When
> > a blockquote continues
> on the right column it makes an extra
> > indent.
> 
> I've fixed the bug and
> pushed the changes to the git repo.  You can
> download a tarball of the
> fixed version (2.6_a) from the mom website:
> 
>  
> https://www.schaffter.ca/mom/mom-05.html#most-recent-release
> 
> -- 
> Peter
> Schaffter
> https://www.schaffter.ca
> 
> 
>