groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Groff] Busgrap


From: Peter Schaffter
Subject: [Groff] Busgrap
Date: Mon, 8 Jun 2015 14:16:47 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

Deri --

Sorry it's taken so long to get around to busgrap.  Been very busy.

I've run busgrap through some initial tests, embedding busgraph in a
mom-formatted document.  In general, no problems.  .BGS/.BGE 
behaves as advertised, including when wrapped inside a FLOAT.  Some
observations, though.

+++Need for macro writers to be able to define .BGS/BGE

As Ralph pointed out, most preprocessors
pass on their bracketing pseudo macros to their output so the
author has the option of defining them.  This is essential for full
integration with mom so she can manage vertical spacing and a few
other issues in a manner consistent with all the other supported
pre-processors.

+++Frame placement

The placement of the frame puts its top edge flush with whatever
baseline precedes .BGS. I think flush with the *next* baseline
would make more sense, but if I can define .BGS (above paragraph),
it doesn't really matter which alignment busgrap uses, at least not
as far as mom is concerned.

+++Caption placement

The default vertical placement of the caption needs to be determined
either

  a) according to the .vs in effect prior to calling .BGS, or
  b) so the top of the ascenders line up with the top of the frame

To my way of thinking, b) is preferable, but a bit tricky to
implement.  a) allows users to do something like

  Caption:\v'.5v'Caption text

with full confidence that .5v is 1/2 the linespacing in effect prior
to .BGS.
  
++Chart placement within frame

Is centering the chart itself within the frame the right default for
placement?  Would it not make more sense to center both chart and
labels inside the frame?  That would seem to be the logical reason
for creating a frame in the first place.  It seems odd, having
established the dimensions of the frame, for labels to hang outside
it.

You might want to consider expanding the Origin keyword so it works
like mom's ADJUST argument (e.g. to FLOAT), i.e. allows for a +|-
value to Xpos and Ypos.  Eyeballing is a lot easier if you can say
"3 points to the left of the default origin and 6 points down", e.g.

  Origin:-6p    +3p

rather than calculating the precise desired Xpos/Ypos.  Regardless,
it would be advantageous if Origin: could adjust the Xpos and Ypos
independently of each other, such that it is possible for users to
change the Xpos without also having to enter a Ypos, whose default
position ("centered") may be difficult to calculate precisely.

+++Local formatting issue (the \s inline)

There's a problem with local formatting that took me by surprise.
Using the example you give in the Introduction (newspaper
circulation), if I do this,

  Series:\s[-4]The Sun  1,978,702
  Series:Daily Mail 1,688,727
  Series:Daily Mirror 992,235

the chart comes out as it should and the labels are 4 points smaller
than the default.  This is the expected behaviour.  Equally, if I do

  Series:\s[-4]The Sun\s[0]     1,978,702
  Series:Daily Mail 1,688,727
  Series:Daily Mirror 992,235

"The Sun" is 4 points smaller, and the size reverts to the default
for "1,978,702" and all subsequent label text.  Also expected
behaviour.  However, if I do

  Series:\s[-4]The Sun  1,978,702\s[0]
  Series:Daily Mail 1,688,727
  Series:Daily Mirror 992,235

the size of all the labels remains at -4, and the chart changes
radically: The Sun's circulation changes from 42.5% to a whopping
88.1%.  Not sure what that's all about, but it certainly isn't what
I expected (though no doubt Mr. Murdoch would be pleased).

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]