Re: Google Summer of Code - LaTeX processing

[Patrick Noffke]

On Wed, Jun 5, 2013 at 2:57 PM, Andrej Lojdl <address@hidden> wrote:
> Today I had more time, so I started reading the code and thinking how to
> control multiline high as Michael proposed. There are some things bugging
> me... I understand that height is expressed in font size and that 64 is some
> scaling factor between font size and size of character on screen. And that
> we save line high in font size (it is expressed in font size). But I don't
> understand how to add this scaling factor? Can someone give me a hint or
> example? When make plot and add title typing title (" text \n text \n text
> \n"), it makes two lines and then, just pack all new lines to second. If I
> get it, this is what needs to be repaired. Is function called once for every
> line or  for whole string?
>

I was just playing around, and I think the problem is more than with
multi-line text.

figure;plot(x,y);title(sprintf('Line 1\nLine 2\nLine 3'), 'FontSize', 24)
 - The lines are drawn somewhat on top of one another.

figure;plot(x,y);title(sprintf('Line 1\nLine 2\nLine 3'), 'FontSize', 10)
 - The lines have enough space between them, but the size of the
bounding box appears to be the same as with 24 pt font.

If you maximize both of the above figures, now there is enough space
for the 24 pt font, but too much space between the lines for 10 pt
font (and again, both bounding boxes appear the same).

You can see the same issue (i.e. the same bounding box size for
different font sizes) with a single line of text:
figure;plot(x,y);title('Title', 'FontSize', 24)
figure;plot(x,y);title('Title', 'FontSize', 10)

I'm still reading the code myself to see if I can determine where the
issue might be.  There does seem to be some extra height added for
multi-line text items, so perhaps once the above font size issue is
handled, multi-line text will look fine.

Andrej, let us know if you find the issue in the meantime.

Also, when I don't use sprintf with titles containing "\n", I only get
a single line of text (with "\n" still in the string).  Matlab behaves
the same way (with a complaint that the TeX interpreter doesn't know
how to interpret the string), so I don't think converting "\n" to a
newline character without using sprintf is necessary.

Pat