Skip to content

mtext adj= wrong with several las= (PR#7188)

7 messages · Paul Murrell, Peter Dalgaard, Uwe Ligges

Original
Uwe Ligges
#
joehl@gmx.de wrote:

            

      
      
      
    

        
Left / right adjustemnt seems to be perfectly OK.
The thing that matters is centering "several lines" to the specified 
("at=") location.
In fact, mtext() is not centering but bottom-aligning by adding a 
negative distance that looks OK for one line in the default font size, 
but not in most other cases.

Hence this is the same as Paul Murrell's PR#1659 ("mtext() alignment of 
perpendicular text"). Fixing this, and/or improving mtext()'s "adj" 
argument to accept 2 dimensions is desirable, but might be not that 
easy... I'll take a look during the next days, but nothing promised.

Uwe Ligges

            

      
      
      
    

  
  


  


    

    
2 days later

    

      
      

        


  

        

      Uwe Ligges
    

    

      
      #
    

  


  

      
ligges@statistik.uni-dortmund.de wrote:

        

            

      
      
      
    

        
Having looked into the code, there are three possible solution (all with
some drawbacks) I can see. Well, the current argument "adj" becomes
"xadj" in the C sources (graphics.c, GMtext), and "yadj" is set to 0. 
Hence the ugly hard coded LineBias of 0.3.


Solutions
=========
1: Hardcode "yadj" to 0.5 and remove all those 0.3 biases. Looks good 
for axes, but it might break some code --> bad.
On the other hand, GMMathText has hardcoded yadj=0.5. Is there a problem 
with some special devices? Or any other reason not to center stuff using 
"adj=0.5"?

2: Allow the typical 2-value adj, take the first as xadj, the second one
as yadj. This might break some code, because currently adj of
arbitrary length (!=0) is allowed and recycled.

3: Invent an argument "padj" for mtext() that represents adjustment
*p*erpendicular to the text direction and gets mapped to "yadj" in
GMtext. In that case the hardcoded 0.3 bias mentioned above can be
removed. The question is whether to set the default to 0.5 (will still
break code, but easily to fix by setting padj to 0).

I'd like to propose the third solution and would be happy to provide a
patch of GMText, including corresponding patches to GMMathText, as well 
as mtext(), title() and axis() (and their inderlying do_* components).

Are there any objections? Any reasons not to do it?

Uwe Ligges

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    
1 day later

    

      
      

        


  

        

      Paul Murrell
    

    

      
      #
    

  


  

      
Hi

        
Uwe Ligges wrote:

            

      
      
      
    

        
It hurts my head to think about this stuff.  There are so many 
combinations to worry about:
(i)   The las setting
(ii)  The axis (bottom, left, top, right)
(iii) Whether adj has been specified
(iv)  Whether the text is multi-line

I think mtext() does ok as long as adj is not specified and the text is 
single-line.

I would suggest addressing the multi-line problem for unspecified adj as 
a first step.  And I will definitely not mourn the passing of the 0.3 
constant.  Setting yadj to 0.5 is not enough though because that doesn't 
make sense for multi-line text that is parallel to an axis (in that 
case, yadj should probably be 0 for axis 2 and 3 and 1 for axis 1 and 4; 
  did I mention that there are lots of combinations to worry about?).

For user-specified adj, I agree that a 2-value adj is not a good 
solution (adj is assumed to be horizontal adjustment) so maybe a padj 
would be best to allow user control of vertical alignment.

Paul

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Uwe Ligges
    

    

      
      #
    

  


  

      
Paul Murrell wrote:

        

            

      
      
      
    

        
Unfortunately it does *not* (using axis() here for simplicity):
   plot(1:10)
   axis(3, cex.axis=5, las=2)

            

      
      
      
    

        
I think most of the stuff is already quite pretty.
The point is whether we are going to distinguish cases for 
(p)adj={0,0.5,1} automatically or not. If the latter, we can omit 
several of the cases mentioned above in (i)-(iv).
I think - as the first step - we should set the default to center (note 
that text() does so as well), and let the user change padj for 
multi-line text as required.

I'll try to provide a collection of patches as a proposal within, say, 
two weeks.

Uwe

            

      
      
      
    

        
>

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Paul Murrell
    

    

      
      #
    

  


  

      
Hi

        
Uwe Ligges wrote:

            

      
      
      
    

        
Good point :)

            

      
      
      
    

        
I think the ideal would be to set padj automatically for multi-line text 
as well as single-line text (the current behaviour tries to set padj 
automatically for single-line text;  it's just not very good at it :).
But whatever first step is good;  then we can more easily discuss actual 
behaviour and code examples.

            

      
      
      
    

        
Great (modulo version scheduling issues discussed elsewhere).
Thanks Uwe!

Paul

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Peter Dalgaard
    

    

      
      #
    

  


  

      
Paul Murrell <p.murrell@auckland.ac.nz> writes:

            

      
      
      
    

        
A somewhat uninformed conjecture: You'll need to look at the TeXbook
again. Think of it like this: A single line of text forms a box that
has a top, a bottom, and a baseline, and you can align on either or on
some fraction between top and bottom. Multiple lines form a box too,
but you need a way to specify whether the baseline of the entire box
is defined by the top or the bottom line inside of it. In addition,
you need to specify alignment inside the box. Basically, we need a
more structured approach than a bunch of options that change meaning
depending on the setting of other options.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Uwe Ligges
    

    

      
      #
    

  


  

      
Peter Dalgaard wrote:

        

            

      
      
      
    

        
I think we already have that (more or less), and we don't want to 
re-implement TeX, I hope (in this case I'm the wrong person given my 
capabilities ;-)).
There is a top and a bottom and the bottom line defined as a baseline.
Then we have (speaking about mtext() now) "adj" that controls the 
right/left adjustment in reading direction. What we do not have is 
adjustment in the perpendicular reading direction - it's simply a fixed 
value that can only be controlled using "at".
All the stuff does not change meaning depending on other options, only 
the defaults are sometimes changing (in order not be be completely ugly).
My aim is (a) to provide the missing argument and (b) to set more 
sensible defaults than that one we already have. It's not that easy 
doing it without breaking code.

Uwe