Thanks to visit codestin.com
Credit goes to github.com

Skip to content

FIX: better handling of multi-line text objects in draw #9775

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

jklymak
Copy link
Member

@jklymak jklymak commented Nov 13, 2017

PR Summary

This does a slightly better job with multiline text for at least the PGF backend, and doesn't seem to
break other backends. See #9747

PGF accepts the original text object for positioning and entering etc. However the previous version would not pass the text object if the text string was multi-lined. The text was placed OK, but based on the default renderer font sizes, which could be quite different from the PGF font sizes. This ruined centering of the two title lines in #9747

This attempts to fix that by passing one text object per line. vertical position is taken from the default layout, which assumes a vertical alignment of bottom so that gets set.

I tried doing this in general, but it breaks other layout choices for single-line text. So it only goes into this layout mode if there are multiple lines.

This fails some hinting tests. Not sure what the status of those are given work @anntzer and @QuLogic are doing on font handling...

PR Checklist

  • Has Pytest style unit tests
  • Code is PEP 8 compliant
  • New features are documented, with examples if plot related
  • Documentation is sphinx and numpydoc compliant
  • Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
  • Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

@anntzer
Copy link
Contributor

anntzer commented Nov 13, 2017

In theory https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/backends/backend_pgf.py#L714 should actually measure the sizes correctly for the pgf backend.

I guess the problem is that the settings of the pgf backend may change between when matplotlib generates the pgf and when the file is actually compiled.

I feel that the proper solution is to have a way for the pgf backend to just tell matplotlib "just pass me the full string, not one line at a time, I (i.e. tex) have a layout manager myself".

@jklymak
Copy link
Member Author

jklymak commented Nov 13, 2017

That'd be nice. You can do multiline in pgf if you use the tabular environment, so thats doable. Though I'm not sure what happens to the line spacing if you do that.

But I think PGF is the only backend to handle this sort of thing. So you'd need to have special logic in draw_text() just to handle that one backend (because the other renderers get fed the string one line at a time).

But I'm open to this not being a good solution. Are there other backends that use the text object like PGF does? If its just PGF, I'm not convinced its used often enough to justify changing the rest of the infrastructure to make it work, and this hack looks fine.

@anntzer
Copy link
Contributor

anntzer commented Nov 13, 2017

Can't you just do multiline in pgf by using '\' (a normal latex newline) (haven't used pgf for a while but wouldn't be surprised if you could)?

In fact if that works I'd suggest just documenting this as the preferred approach for pgf... that'll also get better linespacing (consistent with what tex would do).

@jklymak
Copy link
Member Author

jklymak commented Nov 13, 2017

I don't think so. I tried that:

\pgftext[x=2in,y=4in,left,base]{First \ Second}%

doesn't do anything.

\pgftext[x=2in,y=4in,left,base]{First \\ Second}%

gives:

! LaTeX Error: Something's wrong--perhaps a missing \item.
\pgftext[x=2in,y=4in,left,base]{\begin{tabular}{c} First \\ Second \end{tabular}}

Works fine.

@anntzer
Copy link
Contributor

anntzer commented Nov 13, 2017

@jklymak
Copy link
Member Author

jklymak commented Nov 13, 2017

Yeah, but I don't think that works for PGF. Those are TikZ objects. But I could be doing something else wrong or misunderstanding.

@anntzer
Copy link
Contributor

anntzer commented Nov 13, 2017

Sort of hijacking the thread at that point but looks like my pgf install is broken: compiling

\documentclass[article]
\usepackage{pgf}
\begin{document}
\end{document}

(nothing even with matplotlib) gives

This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) (preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./foo.tex
LaTeX2e <2016/03/31> patch level 3
Babel <3.9r> and hyphenation patterns for 4 language(s) loaded.
! TeX capacity exceeded, sorry [parameter stack size=10000].
\@fileswithoptions #1->
                       \@ifnextchar [{\@fileswith@ptions #1}{\@fileswith@pti...
l.2 \usepackage{
                pgf}
!  ==> Fatal error occurred, no output PDF file produced!
Transcript written on foo.log.

any hint?

@jklymak
Copy link
Member Author

jklymak commented Nov 13, 2017

I just used the example in #9747 that uses \usepackage{pgfplots} I use TexLive...

@anntzer
Copy link
Contributor

anntzer commented Nov 13, 2017

Ah, I don't know how to write a latex preamble anymore. My bad.

@anntzer
Copy link
Contributor

anntzer commented Nov 13, 2017

https://tex.stackexchange.com/questions/53704/can-i-put-a-line-break-in-pgftext should work though (modulo whatever fixes are needed in the pgf backend)...

@jklymak
Copy link
Member Author

jklymak commented Nov 14, 2017

But again, we pass to renderer.draw_text() by line. Is it worth putting a separate logic in here just for PGF?

@jklymak
Copy link
Member Author

jklymak commented Nov 14, 2017

Even worse, I only know that its a matplotlib.backends.backend_mixed.MixedModeRenderer at this point of the code, so I can't even put logic in based on whether we are outputting PGF or not...

@jklymak
Copy link
Member Author

jklymak commented Nov 16, 2017

OK, I'm going to close this. The OP found that properly specifying the fonts in their rcParams did the trick of lining up the characters properly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants