Unicode Art #18357

vbraun · 2015-05-03T18:56:58Z

There should be a variant of ascii art using unicode. It should share code with ascii art as appropriate.

Also, there are various typesetting-related modules in sage.misc: ascii art, latex, mathjax, .... They should be moved into a common package. I propose sage.typeset

CC: @sagetrac-elixyre

Component: user interface

Author: Volker Braun, Vincent Delecroix

Branch/Commit: a6cf84f

Reviewer: Vincent Delecroix, Volker Braun

Issue created by migration from https://trac.sagemath.org/ticket/18357

The text was updated successfully, but these errors were encountered:

videlec · 2015-05-03T19:21:18Z

comment:2

What would be your strategy here? A method _unicode_art_ on objects?

vbraun · 2015-05-03T19:23:15Z

comment:3

Yes, objects should use _unicode_art_ to hook into unicode art generation.

vbraun · 2015-05-04T01:37:24Z

Branch: u/vbraun/unicode_art

novoselt · 2015-05-14T18:22:04Z

Commit: c8317b2

novoselt · 2015-05-14T18:22:04Z

comment:5

Is it feasible to have generation of such art from _latex_ methods when no special one is provided? Is anyone aware of good converters? MathJax 2.5 has that "fast HTML preview" that appears before the formula is properly rendered, but it does not support \hline and other frame parts of arrays, for example.

New commits:

`c8317b2`	`initial implementation of unicode art`

vbraun · 2015-05-14T18:33:09Z

comment:6

The closest I know is http://asciitex.sourceforge.net, though really I don't think its feasible for complicated equations...

sagetrac-git · 2015-05-16T20:34:13Z

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

`de3440a`	`initial implementation of unicode art`
`a73beee`	`Add a OutputUnicodeArt rich output type`

sagetrac-git · 2015-05-16T20:34:13Z

Changed commit from c8317b2 to a73beee

sagetrac-git · 2015-05-16T20:42:16Z

Changed commit from a73beee to 3ed994d

sagetrac-git · 2015-05-16T20:42:16Z

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

`3ed994d`	`Add a OutputUnicodeArt rich output type`

vbraun · 2015-05-16T20:42:56Z

comment:9

Analogous to ascii art, the following works now:

sage: %display unicode_art
sage: identity_matrix(ZZ, 2)
⎛1 0⎞
⎝0 1⎠

videlec · 2015-05-16T20:51:09Z

comment:10

Replying to @vbraun:

Analogous to ascii art, the following works now:

Nice!

Though, on 6.7.rc0 I got

sage: %display unicode_art
value must be unset (None) or one of ('plain', 'ascii_art', 'latex'), got unicode_art

Vincent

videlec · 2015-05-16T20:54:35Z

comment:11

Replying to @videlec:

Replying to @vbraun:

Analogous to ascii art, the following works now:

Nice!

Though, on 6.7.rc0 I got...

It works perfectly fine after applying the branch! Sorry for the noise.

videlec · 2015-05-16T21:21:28Z

comment:12

Argh, the Dyck paths looks ugly. I am trying to do something but the BOX DIAGONALS do not match very well...

Do you know why in the ipython notebook we got a failure

sage: unicode_art(matrix([[2,2],[1,1]]))
Traceback (most recent call last):
...
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 1: ordinal not in range(128)

Vincent

videlec · 2015-05-16T22:53:38Z

comment:13

A commit with unicode art for Dyck paths and Tableaux at u/vdelecroix/18357.

sagetrac-git · 2015-05-16T23:10:50Z

Changed commit from 3ed994d to e41f4f6

sagetrac-git · 2015-05-16T23:10:50Z

Branch pushed to git repo; I updated commit sha1. New commits:

`e41f4f6`	`Always use unicode for IPython backend`

sagetrac-git · 2015-05-16T23:13:45Z

Branch pushed to git repo; I updated commit sha1. New commits:

`7616a94`	`Trac 18357: unicode art for Dyck words and Tableaux`
`26e6221`	`Merge branch 'u/vdelecroix/18357' #18357`

sagetrac-git · 2015-05-16T23:13:45Z

Changed commit from e41f4f6 to 26e6221

vbraun · 2015-05-16T23:16:51Z

comment:16

Fixed the IPython issue, it wants unicode instead of utf-8 encoded bytes.

I merged your branch

videlec · 2015-05-17T08:56:17Z

comment:17

Thanks for the inclusion.

I got other troubles with the Ipython notebook:

with %display unicode it can not export in pdf because latex failed

...
    ! Package ucs Error: Unknown Unicode character 9115 = U+239B,
    (ucs)                possibly declared in uni-35.def.
    (ucs)                Type H to see if it is available with options.
...
    l.225 ...lor}Out[{\color{outcolor}15}]:} ⎛2 2⎞
                                                      
    ? 
    ! Emergency stop.
     ...                                              
                                                      
    l.225 ...lor}Out[{\color{outcolor}15}]:} ⎛2 2⎞
                                                      
    !  ==> Fatal error occurred, no output PDF file produced!
    Transcript written on notebook.log.

if %display latex then it works fine in the browser for matrices but not for tableaux or Dyck paths. More precisely, I see the latex code.
if %display latex then after an export pdf, the output which is exported is not the latex one but the plain text! I thought that latex would be the ideal mode for notebooks for both the display and the export...

Vincent

vbraun · 2015-05-17T09:49:08Z

comment:18

%display latex uses Sage's mathjax/latex. In particular, matrices are typeset by mathjax and not by this branch. Sage's latex also has problems with unicode that are unrelated to this ticket:

sage: latex(u'Motörhead')
---------------------------------------------------------------------------
UnicodeEncodeError                        Traceback (most recent call last)
<ipython-input-4-0cfcb5f9dc0d> in <module>()
----> 1 latex(u'Motörhead')

/home/vbraun/Sage/git-develop/local/lib/python2.7/site-packages/sage/misc/latex.pyc in __call__(self, x, combine_all)
    925             return LatexExpr(f(x))
    926         except KeyError:
--> 927             return LatexExpr(str_function(str(x)))
    928 
    929 

UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in position 3: ordinal not in range(128)

vbraun · 2015-05-17T09:56:38Z

comment:19

Upstream bug for PDF export with unicode ipython/ipython#7150 (closed as wontfix)

videlec · 2015-05-17T10:05:25Z

comment:20

Replying to @vbraun:

Upstream bug for PDF export with unicode ipython/ipython#7150 (closed as wontfix)

It is the author of the request who closes the issue... not sure it is a won't fix but he did not say how he fixed it for himself. Anyway, it looks like a Ipython notebook issue and not a Sage one. Would be nice to have this "export to pdf" feature using the latex output!

sagetrac-git · 2015-05-17T11:57:30Z

Branch pushed to git repo; I updated commit sha1. New commits:

`9a2405a`	`use named constants instead of literals for matrix unicode art`

vbraun · 2015-05-26T21:38:57Z

comment:49

There are a number of doctest failures due to different baselines because of your changes, like:

File "src/sage/combinat/binary_tree.py", line 2511, in sage.combinat.binary_tree.BinaryTree.under
Failed example:
    ascii_art((b1, b2, b1 \ b2))
Expected:
    (   o    o        _o_   )
    (  / \    \      /   \  )
    ( o   o,   o,   o     o )
    (              / \      )
    (             o   o     )
Got:
    (   o  , o  ,     _o_   )
    (  / \    \      /   \  )
    ( o   o    o    o     o )
    (              / \      )
    (             o   o     )

IMHO the previous baseline was better.

videlec · 2015-05-27T15:14:42Z

comment:50

Right. Sorry. With a one line modification I get the previous behavior. But do you really think that we should keep this behavior

            [                                       ]
            [ , o, ,   _o_        o      o      o   ]
            [         /   \             / \         ]
            [        o     o           o   o        ]
            [             / \                       ]
            [            o   o, ,  , ,      , ,  ,  ]

Would be better with all commas at the same position, isn't it?

Vincent

vbraun · 2015-05-27T15:22:53Z

comment:51

I think ideally the boxes are vertically aligned along their baseline (=bottom of the box in this case):

            [                                       ]
            [          _o_                          ]
            [         /   \                         ]
            [        o     o             o          ]
            [             / \           / \         ]
            [ , o, ,     o   o, , o, , o   o, , o,  ]

though we don't necessarily have to do it on this ticket.

sagetrac-git · 2015-05-27T17:11:25Z

Changed commit from 2b0207c to a27bfe5

sagetrac-git · 2015-05-27T17:11:25Z

Branch pushed to git repo; I updated commit sha1. New commits:

`a27bfe5`	`Trac #18357: fix the position of the separator for lists`

videlec · 2015-05-27T17:12:53Z

comment:53

Replying to @vbraun:

I think ideally the boxes are vertically aligned along their baseline (=bottom of the box in this case):

though we don't necessarily have to do it on this ticket.

I hope it implies "you can do it". I did a test all and it went smoothly.

Vincent

vbraun · 2015-05-27T19:53:31Z

comment:54

The commas are now on the common base line, but the constituent object is still top-aligned instead of aligned on the baseline:

[ o    o   ]     
[     / \  ]     
[  , o   o ]

instead of

[      o   ]     
[     / \  ]     
[ o, o   o ]

videlec · 2015-05-27T20:08:43Z

comment:55

I am not responsible for that (with current develop version)

sage: b3 = BinaryTrees(3).an_element()
sage: b1 = BinaryTrees(1).an_element()
sage: ascii_art(b1) + ascii_art(b3) + ascii_art(b1)
oo    o
  \   
   o  
    \ 
     o

You would like to change the semantic of __add__? Of course it would make sense that the objects get aligned on their baseline (I thought it was precisely the purpose of baseline).

That way, I could remove the current hack for the separator as it will naturally appear on the baseline.

vbraun · 2015-05-27T20:51:22Z

comment:56

I think that we should follow the usual glyph layout convention, which always aligns on the baseline as you said. Right now its pretty confusing to have such a huge space between the top-aligned object and the comma at the bottom.

videlec · 2015-05-30T17:21:06Z

comment:57

Actually, this is the expected behavior. Baselines are computed from the bottom, not from the top (this is crazy to me). In particular, the baseline of a tree is at its root (which is comprehensible).

vbraun · 2015-05-30T18:28:22Z

comment:58

Ok, I wasn't aware that the trees have their baseline at the top. Thats a valid design choice for trees I guess. Then we should revert the last commit (but fix the doctests) to display as

    (   o  , o  ,     _o_   )
    (  / \    \      /   \  )
    ( o   o    o    o     o )
    (              / \      )
    (             o   o     )

vbraun · 2015-05-30T18:33:32Z

comment:59

PS: In an ideal world we would have kerning to move the commas in:

    (   o,   o,       _o_   )
    (  / \    \      /   \  )
    ( o   o    o    o     o )
    (              / \      )
    (             o   o     )

sagetrac-git · 2015-05-31T20:31:22Z

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

`7378e2f`	`Trac #18357: merge sage-6.8.beta2`
`a6cf84f`	`Trac #18357: fix doctests`

sagetrac-git · 2015-05-31T20:31:22Z

Changed commit from a27bfe5 to a6cf84f

vbraun · 2015-06-02T14:42:12Z

Changed branch from u/vdelecroix/18357 to a6cf84f

vbraun added this to the sage-6.7 milestone May 3, 2015

vbraun added the p: major / 3 label May 3, 2015

This comment has been minimized.

Sign in to view

vbraun added t: enhancement labels May 3, 2015

vbraun added the s: positive review label May 26, 2015

vbraun added s: needs work and removed s: positive review labels May 26, 2015

videlec added s: needs info and removed s: needs work labels May 27, 2015

videlec added s: needs review and removed s: needs info labels May 31, 2015

vbraun added s: positive review and removed s: needs review labels May 31, 2015

vbraun removed the s: positive review label Jun 2, 2015

vbraun closed this as completed in d619eb9 Jun 2, 2015

vbraun mentioned this issue May 5, 2015

Print matrices using unicode large delimiters (on demand) #18270

Closed

gagern mannequin mentioned this issue Dec 29, 2022

Unicode support in reference manual and other docs, e.g. developer manual #18370

Closed

vbraun mentioned this issue Jun 20, 2015

Unicode art for symbolics #18482

Closed

fchapoton mentioned this issue Sep 15, 2018

remove deprecated stuff in character art #26273

Closed

Unicode Art #18357

Unicode Art #18357

Comments

vbraun commented May 3, 2015

This comment has been minimized.

videlec commented May 3, 2015

vbraun commented May 3, 2015

vbraun commented May 4, 2015

novoselt commented May 14, 2015

novoselt commented May 14, 2015

vbraun commented May 14, 2015

sagetrac-git mannequin commented May 16, 2015

sagetrac-git mannequin commented May 16, 2015

sagetrac-git mannequin commented May 16, 2015

sagetrac-git mannequin commented May 16, 2015

vbraun commented May 16, 2015

videlec commented May 16, 2015

videlec commented May 16, 2015

videlec commented May 16, 2015

videlec commented May 16, 2015

sagetrac-git mannequin commented May 16, 2015

sagetrac-git mannequin commented May 16, 2015

sagetrac-git mannequin commented May 16, 2015

sagetrac-git mannequin commented May 16, 2015

vbraun commented May 16, 2015

videlec commented May 17, 2015

vbraun commented May 17, 2015

vbraun commented May 17, 2015

videlec commented May 17, 2015

sagetrac-git mannequin commented May 17, 2015

vbraun commented May 26, 2015

videlec commented May 27, 2015

vbraun commented May 27, 2015

sagetrac-git mannequin commented May 27, 2015

sagetrac-git mannequin commented May 27, 2015

videlec commented May 27, 2015

vbraun commented May 27, 2015

videlec commented May 27, 2015

vbraun commented May 27, 2015

videlec commented May 30, 2015

vbraun commented May 30, 2015

vbraun commented May 30, 2015

sagetrac-git mannequin commented May 31, 2015

sagetrac-git mannequin commented May 31, 2015

vbraun commented Jun 2, 2015