Fix long arrows in Unicode pretty printing. #1440

Merged
merged 2 commits into from Aug 1, 2012

Conversation

Projects
None yet
7 participants
Contributor

scolobb commented Jul 24, 2012

Previously those classes were pretty printed using long Unicode symbols,
which worked erratically on different terminals. This commit uses more
standard characters.

Things are now printed like this:

{g∘f:A₁——▶C₁: ∅, id:A₁——▶A₁: ∅, id:B——▶B: ∅, id:C₁——▶C₁: ∅, f:A₁——▶B: ∅, g:B——▶C₁: ∅} 
══▶ {g∘f:A₁——▶C₁: {unique}}

Thanks to @asmeurer for the suggestion!

Contributor

scolobb commented Jul 24, 2012

While I am about arrows, if anyone would like any arrow printing to changed in a similar way, feel free to point the places, I'll do the work. @ness, do you maybe like these arrows more that your current version?

This pull request fails (merged fb3fe98a into c84e5df).

Owner

asmeurer commented Jul 24, 2012

Interesting. In the mail app on my iPad these show up as ▶️

Owner

asmeurer commented Jul 24, 2012

And if I use the emoji keyboard to type that I get ▶

Owner

asmeurer commented Jul 24, 2012

You should use pretty_symbology.py.

Owner

asmeurer commented Jul 24, 2012

Also the em dash is rendering as two dashes. I only notice this in a non mono space font, though, so maybe it won't be an issue.

Contributor

scolobb commented Jul 24, 2012

You should use pretty_symbology.py.

Will do.

Also the em dash is rendering as two dashes.

I have actually put two em dashes there, on my terminal it looks better. Do you think I should use one dash instead?

Owner

asmeurer commented Jul 24, 2012

Oh OK. I was just worried that the em dash was expanding.

Member

Krastanov commented Jul 24, 2012

SymPy Bot Summary: 🔴 There were test failures.

@scolobb: Please fix the test failures.

Test command: setup.py test
master hash: c84e5df
branch hash: fb3fe98a07d3f196c5c2311e11a1611f009ad3ec

Interpreter 1: 🔴 There were test failures.

Interpreter: /usr/local/bin/python2.5 (2.5.6-final-0)
Architecture: Linux (64-bit)
Cache: yes

Test results html report: http://reviews.sympy.org/report/agZzeW1weTNyDAsSBFRhc2sYzvchDA

Interpreter 2: 🔴 There were test failures.

Interpreter: /usr/bin/python2.7 (2.7.3-candidate-2)
Architecture: Linux (64-bit)
Cache: yes

Test results html report: http://reviews.sympy.org/report/agZzeW1weTNyDAsSBFRhc2sYtf8hDA

Interpreter 3: 🔴 There were test failures.

Interpreter: /usr/bin/python3.2 (3.2.3-candidate-2)
Architecture: Linux (64-bit)
Cache: yes

Test results html report: http://reviews.sympy.org/report/agZzeW1weTNyDAsSBFRhc2sYzfchDA

Build HTML Docs: 🔴 There were test failures.

Docs build command: make html-errors
Sphinx version: 1.1.3

Test results html report: http://reviews.sympy.org/report/agZzeW1weTNyDAsSBFRhc2sY5e8hDA

Automatic review by SymPy Bot.

Contributor

ness01 commented Jul 25, 2012

Not to be a killjoy here, but this doesn't really look good on my terminal: http://imageshack.us/photo/my-images/99/morphism.png/

Owner

asmeurer commented Jul 25, 2012

@ness01 what font is that?

Member

smichr commented Jul 25, 2012

Notice that there is a space after the key that is to the right of the arrow, but not one after the key that is on the left side of the arrow. k:v-->k: v

Contributor

ness01 commented Jul 25, 2012

On 25.07.2012 19:37, Aaron Meurer wrote:

@ness01 what font is that?

Hm. I have been trying for half an hour to figure it out, now I give up.
It is the default font of urxvt in debian. Anyone know how to get urxvt
to display what actual font it is using?

Contributor

scolobb commented Jul 25, 2012

Not to be a killjoy here, but this doesn't really look good on my terminal: http://imageshack.us/photo/my-images/99/morphism.png/

@asmeurer , looks like this is one of those fonts where the dash is not centered :-(

What do you people think would be a way out here? @ness01, that screenshot surely doesn't look cool. Yet, does the version with ">" for an arrow head look better for you?

I tried figuring out the default font in urxvt, and failed as well. I think the question may boil down to estimating how many people use terminals with non-centered horizontal dashes.

Contributor

scolobb commented Jul 25, 2012

According to what I see http://stackoverflow.com/a/6325076/971680 , I guess urxvt default font doesn't render the triangles correctly, because what I see looks rather like a small triangle. I may be wrong, of course.

@ness01 , I have just installed urxvt myself, but, without configuring .Xresources I can't get it to render any SymPy Unicode characters at all :-( I'm not sure as to the build flags, I don't use urxvt too often. Could you please tell how this —→ looks in your terminal?

Also, maybe we could transition to using one-character arrows, like in A→B? I know it looks a little bit too condensed, but then, it may be worth it since we can't get consistent output with more-than-one-character arrows?

Contributor

scolobb commented Jul 25, 2012

Notice that there is a space after the key that is to the right of the arrow, but not one after the key that is on the left side of the arrow. k:v-->k: v

@smichr , that's because k:v-->k is actually the key, and v is the value. The point is that Diagram stores two dictionaries mapping morphisms to sets; morphisms are rendered as k:v-->k and values are rendered as v, while the : between them is produced by standard dict printing code.

Contributor

ness01 commented Jul 25, 2012

On 25.07.2012 20:49, Sergiu Ivanov wrote:

According to what I see http://stackoverflow.com/a/6325076/971680 , I guess urxvt default font doesn't render the triangles correctly, because what I see looks rather like a small triangle. I may be wrong, of course.

I'm not sure how to figure this out, but if so, I think it would be
valid to just file a bug against urxvt (or the debian package).

@ness01 , I have just installed urxvt myself, but, without configuring .Xresources I can't get it to render any SymPy Unicode characters at all :-(

What distro are you on?

I'm not sure as to the build flags, I don't use urxvt too often. Could you please tell how this —→ looks in your terminal?

A non-centred dash followed by an ordinary arrow. Somewhat like _->.

Also, maybe we could transition to using one-character arrows, like in A→B? I know it looks a little bit too condensed, but then, it may be worth it since we can't get consistent output with more-than-one-character arrows?

This might be best ... it's really quite frustrating, though not
terribly surprising, to see that terminals don't display unicode
consistently.

Contributor

scolobb commented Jul 25, 2012

What distro are you on?

I'm on Gentoo. I guess I should build it with some additional build flags to get those Unicode characters; I didn't really try to figure that out.

A non-centred dash followed by an ordinary arrow. Somewhat like _->.

I see :-(

http://xahlee.info/comp/unicode_arrows.html -- there's an assortment of arrows; we could choose between the one-character simple ones:

(1) A➔B (2) A➙B (3) A➛B (4) A➜B (5) A➝B (6) A➞B (7) A➡B

For me, (4) looks best: it is sufficiently thick and the head is distinguishable. I use DejaVu Sans Mono Book, 8.

Contributor

ness01 commented Jul 25, 2012

On 25.07.2012 21:12, Sergiu Ivanov wrote:

What distro are you on?

I'm on Gentoo. I guess I should build it with some additional build flags to get those Unicode characters; I didn't really try to figure that out.

A non-centred dash followed by an ordinary arrow. Somewhat like _->.

I see :-(

http://xahlee.info/comp/unicode_arrows.html -- there's an assortment of arrows; we could choose between the one-character simple ones:

(1) A➔B (2) A➙B (3) A➛B (4) A➜B (5) A➝B (6) A➞B (7) A➡B

For me, (4) looks best: it is sufficiently thick and the head is distinguishable. I use DejaVu Sans Mono Book, 8.

For me, (3), (4) and (5) look bad, all others look the same.

Contributor

scolobb commented Jul 25, 2012

For me, (3), (4) and (5) look bad, all others look the same.

Oh wow :-( OK, I think I'll way for more people to react in order to gather some statistics.

Owner

asmeurer commented Jul 25, 2012

As I noted on IRC, it's more of a unicode problem in general. Terminals rely a large part on the underlying operating system's unicode support, including things like font substitution for when a font doesn't contain a given character. The exception to this is that most terminals (or at least the ones I've used) enforce that characters are monospaced, even when they really aren't.

Here's what it looks like for me with the font DejaVu Sans Mono img

(you'll also note that things look better than @ness01's in general, in part because I have antialiasing enabled)

Contributor

scolobb commented Jul 25, 2012

@asmeurer , yes, right. Arrows render in the same way in my terminal, and I actually like this option much better than the others as far as my terminal is concerned. However, I'm not sure what decision to take in what concerns support for fonts with off-center em dashes and unexpected size of triangles.

Contributor

ness01 commented Jul 25, 2012

On 25.07.2012 21:29, Sergiu Ivanov wrote:

@asmeurer , yes, right. Arrows render in the same way in my terminal, and I actually like this option much better than the others as far as my terminal is concerned. However, I'm not sure what decision to take in what concerns support for fonts with off-center em dashes and unexpected size of triangles.

ftr, I don't want to be a blocker here. I'm ok with changing my font
setting. But I think there are quite a few people out there using rxvt
with standard fonts on debian...

Owner

asmeurer commented Jul 25, 2012

I should point out that this wouldn't be the first printing thing that looks bad, or at least non-ideal, with poor font settings.

Member

smichr commented Jul 25, 2012

On Thu, Jul 26, 2012 at 1:59 AM, Tom Bachmann <
reply@reply.github.com

wrote:

On 25.07.2012 21:12, Sergiu Ivanov wrote:

What distro are you on?

I'm on Gentoo. I guess I should build it with some additional build
flags to get those Unicode characters; I didn't really try to figure that
out.

A non-centred dash followed by an ordinary arrow. Somewhat like _->.

I see :-(

http://xahlee.info/comp/unicode_arrows.html -- there's an assortment of
arrows; we could choose between the one-character simple ones:

(1) A➔B (2) A➙B (3) A➛B (4) A➜B (5) A➝B (6) A➞B (7) A➡B

1 and 4 look about the same, though the arrow head is a little fatter on 4
and looks better
2 is too short, but otherwise looks like 5 and 6
3 is ok, but looks a little indistinct
5 and 6 are about the same, with 5 having a slightly clearer head
7 is has a chubby shaft and doesn't have a very distinct head
I think my favorite is 4 or 5

Owner

asmeurer commented Jul 26, 2012

In my opinion, -> looks better than any of the single character arrows.

Contributor

scolobb commented Jul 26, 2012

@smichr , thanks for the feedback!

@ness01 , @asmeurer , what do you think of the version we have in this pull request, i.e., of the arrows composed of two em dashes and a black right-pointing triangle A₁——▶C₁? Do I change it to one of the one-character arrows or even ->?

I would personally vote for the current version. The one-character arrows are rather difficult to read.

Member

smichr commented Jul 26, 2012

On Thu, Jul 26, 2012 at 4:01 PM, Sergiu Ivanov <
reply@reply.github.com

wrote:

@smichr , thanks for the feedback!

@ness01 , @asmeurer , what do you think of the version we have in this
pull request, i.e., of the arrows composed of two em dashes and a black
right-pointing triangle A₁——▶C₁? Do I change it to one of the
one-character arrows or even ->?

What appears above looks perfect (though a bit long) to me here. I don't
really like the -> version since for me this has the dash vertically
lower than the vertex in the >.

Contributor

scolobb commented Jul 26, 2012

What appears above looks perfect (though a bit long) to me here. I don't
really like the -> version since for me this has the dash vertically
lower than the vertex in the >.

Could you please paste A₁——▶C₁ in the terminal you are using? It looks too long in the browser for me, but quite all right in the terminal (maybe that's because of the font size, which is 8 for me).

-> looks similarly for me, the dash is lower than the center of >, and I find that rather unpleasant, too.

Member

smichr commented Jul 26, 2012

On Thu, Jul 26, 2012 at 6:17 PM, Sergiu Ivanov <
reply@reply.github.com

wrote:

What appears above looks perfect (though a bit long) to me here. I don't
really like the -> version since for me this has the dash vertically
lower than the vertex in the >.

Could you please paste A₁——▶C₁ in the terminal you are using? It looks
too long in the browser for me, but quite all right in the terminal (maybe
that's because of the font size, which is 8 for me).

Sorry, neither subscripts nor arrowhead are supported in my current
configuration of terminals.

@scolobb scolobb Fix long arrows in Unicode pretty printing of category theoretic clas…
…ses.

Previously those classes were pretty printed using long Unicode symbols,
which worked erratically on different terminals.  This commit uses more
standard characters.
925adb4
Contributor

scolobb commented Jul 29, 2012

I have changed the pretty printing code to use pretty_symbology.py.

Note that 804bbde introduces a nontrivial change, explained in the commit message.

Member

Krastanov commented Jul 29, 2012

SymPy Bot Summary: 🔴 There were test failures.

@scolobb: Please fix the test failures.

Test command: setup.py test
master hash: 9ad73da
branch hash: cbbd2b6c478fd26ab2d30d5af37e2c1d6596f063

Interpreter 1: 🔴 There were test failures.

Interpreter: /usr/local/bin/python2.5 (2.5.6-final-0)
Architecture: Linux (64-bit)
Cache: yes

Test results html report: http://reviews.sympy.org/report/agZzeW1weTNyDAsSBFRhc2sYufwiDA

Interpreter 2: 🔴 There were test failures.

Interpreter: /usr/bin/python2.7 (2.7.3-candidate-2)
Architecture: Linux (64-bit)
Cache: yes

Test results html report: http://reviews.sympy.org/report/agZzeW1weTNyDAsSBFRhc2sY7OwiDA

Interpreter 3: 🔴 There were test failures.

Interpreter: /usr/bin/python3.2 (3.2.3-candidate-2)
Architecture: Linux (64-bit)
Cache: yes

Test results html report: http://reviews.sympy.org/report/agZzeW1weTNyDAsSBFRhc2sY95YiDA

Build HTML Docs: ✳️ All tests have passed.

Docs build command: make html-errors
Sphinx version: 1.1.3

Test results html report: http://reviews.sympy.org/report/agZzeW1weTNyDAsSBFRhc2sY7-8hDA

Automatic review by SymPy Bot.

This pull request passes (merged 5d91875a into 5e2cf47).

This pull request fails (merged cbbd2b6c into 9ad73da).

Member

Krastanov commented Jul 29, 2012

SymPy Bot Summary: 🔴 There were test failures.

@scolobb: Please fix the test failures.

Test command: setup.py test
master hash: 5e2cf47
branch hash: 5d91875a1cd89936ef591fcc595ab2ed0bb1bcbb

Interpreter 1: ✳️ All tests have passed.

Interpreter: /usr/local/bin/python2.5 (2.5.6-final-0)
Architecture: Linux (64-bit)
Cache: yes

Test results html report: http://reviews.sympy.org/report/agZzeW1weTNyDAsSBFRhc2sYwv8hDA

Interpreter 2: 🔴 There were test failures.

Interpreter: /usr/bin/python2.7 (2.7.3-candidate-2)
Architecture: Linux (64-bit)
Cache: yes

Test results html report: http://reviews.sympy.org/report/agZzeW1weTNyDAsSBFRhc2sY1_QiDA

Interpreter 3: 🔴 There were test failures.

Interpreter: /usr/bin/python3.2 (3.2.3-candidate-2)
Architecture: Linux (64-bit)
Cache: yes

Test results html report: http://reviews.sympy.org/report/agZzeW1weTNyDAsSBFRhc2sY-ZYiDA

Build HTML Docs: ✳️ All tests have passed.

Docs build command: make html-errors
Sphinx version: 1.1.3

Test results html report: http://reviews.sympy.org/report/agZzeW1weTNyDAsSBFRhc2sYzaYiDA

Automatic review by SymPy Bot.

@scolobb scolobb Use pretty_symbology.py when pretty printing morphisms and diagrams.
The Unicode-related logic was previously incorporated directly into the
pretty printing functions.
2fe40e8

This pull request fails (merged 2fe40e8 into 3519951).

Member

Krastanov commented Jul 30, 2012

SymPy Bot Summary: 🔴 There were test failures.

@scolobb: Please fix the test failures.

Test command: setup.py test
master hash: 3519951
branch hash: 2fe40e8

Interpreter 1: 🔴 There were test failures.

Interpreter: /usr/local/bin/python2.5 (2.5.6-final-0)
Architecture: Linux (64-bit)
Cache: yes

Test results html report: http://reviews.sympy.org/report/agZzeW1weTNyDAsSBFRhc2sY_ZYiDA

Interpreter 2: 🔴 There were test failures.

Interpreter: /usr/bin/python2.7 (2.7.3-candidate-2)
Architecture: Linux (64-bit)
Cache: yes

Test results html report: http://reviews.sympy.org/report/agZzeW1weTNyDAsSBFRhc2sYoIQjDA

Interpreter 3: 🔴 There were test failures.

Interpreter: /usr/bin/python3.2 (3.2.3-candidate-2)
Architecture: Linux (64-bit)
Cache: yes

Test results html report: http://reviews.sympy.org/report/agZzeW1weTNyDAsSBFRhc2sYm7YiDA

Build HTML Docs: 🔴 There were test failures.

Docs build command: make html-errors
Sphinx version: 1.1.3

Test results html report: http://reviews.sympy.org/report/agZzeW1weTNyDAsSBFRhc2sYsq4iDA

Automatic review by SymPy Bot.

Contributor

ness01 commented Jul 31, 2012

The failure is only a timeout and should be fine, right?

Contributor

scolobb commented Jul 31, 2012

The failure is only a timeout and should be fine, right?

Looks like that, as far as travisbot is concerned. As for Stefan's sympy-bot -- I'm not really sure about the reason for Python 2.5 "Could not allocate memory" failure. I've been too lazy recently to run the Python 2.5 test suite on my computer to check the reason; however, I keep getting the same failure on my other pull requests, which makes me think that it's unrelated.

Owner

asmeurer commented Jul 31, 2012

@Krastanov, can you make sure you've got the latest version of SymPy bot (I've merged Sean's branch)?

@ness01 ness01 added a commit that referenced this pull request Aug 1, 2012

@ness01 ness01 Merge pull request #1440 from scolobb/long-unicode-arrows
Fix long arrows in Unicode pretty printing.
a67d688

@ness01 ness01 merged commit a67d688 into sympy:master Aug 1, 2012

1 check failed

default
Details
Contributor

ness01 commented Aug 1, 2012

This is in :-).

Contributor

scolobb commented Aug 1, 2012

Yeeeaah :-) Thank you, it's just in time for my next changes :-)

Coverage Status

Changes Unknown when pulling 2fe40e8 on scolobb:long-unicode-arrows into * on sympy:master*.

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