Unicode 13.0 added 1/6 block characters at 1FB00-1FB3B in the Characters for Legacy Computing block. This would be a nice complement to the 1/4, 1/2, and 1/8 (Braille) modes.

Trying to use this library to convert images to block characters. So far it's working great.

One point of confusion for me is how to control the size of the output. For context, I'm trying to preserve the ratio of the image, but constrain either its height or width so that it can fit within an arbitrary space.

Here I attempt—and fail—to read in an image and constrain its output to 30 characters in width.

import io

import terminedia
from PIL import Image

screen = terminedia.Screen(backend="ANSI")
resolution = "square"
size = terminedia.V2(x=30, y=30)

image = Image.open("Ent_Steven-Universe_SOCIAL.jpeg")
img = terminedia.shape(
    image,
    size=size,
    promote=True,
    resolution=resolution,
)
output = io.StringIO()
img.render(output=output, backend="ANSI")

print(output.getvalue())
print("-" * 30)  # Ruler to visualize 30 units across 

It renders perfectly, but is wider than 30 characters.

I'm trying to understand:

1. What does the size argument actually do? The resulting image is not 30x30.
2. What's the best way to accomplish my goal—preserving the original aspect ratio of an image while restraining the height and the width to be within a certain number of characters?

(Again) thanks for the project!

terminedia-plot without any parameters works just fine, as in the demo screenshot.

However, trying to provide any other function results a semi garbled output with many fragments of escape characters:

$ terminedia-plot --func x

I've used the latest version this repo: pip install git+https://github.com/jsbueno/terminedia.

When trying to test this libary via pytest, an exception is raised: redirected stdin is pseudofile, has no fileno(). This is due to this line:

https://github.com/jsbueno/terminedia/blob/96f44a67dd97acfd49062c7be30057c6767b2de6/terminedia/terminal.py#L92

It seems that terminedia-plot plots points at a wrong y coordinate.

For instance, terminedia-plot --func x yields: From the graph, I'm getting an impression that f(0.01) ≈ 2, which is obviously not even remotely true for f(x) = x.

(One can also see a minor cosmetic issue, a data point seems to be missing on the graph.)

terminedia-plot --func x*x seems to provide a roughly correct data point for (0, 0), but the choice for y range seems to be quite odd:

When rendering rich-text:

• correctly detect if final transformed character takes more than 1 cell width after applying effects, and correctly use 2 cells for character [WIP] - retrieve last-character width after calling Shape.__setitem__ - check that last-character width works with multiple-character grapheme - allow Shape.__setitem__ to set character to the left of given position if a special attribute is set in the context (and maybe if direction==Right) - Double check and maybe extend role of "Continuation" sentinel character code (used in Shape): - Does it make sense for "Continuation" to indicate the "come from" direction, and allow continuation for custom double-height characters? - implement a dry-run extents call in TextPlane

When printing text with the text-planes mechanism, one can embed a Mark (an object similiar to an HTML tag to dictate attributes to the text from that point on), fixed on a TextPlane position - for example, doing:

screen.text[1].marks[5,0] = TM.Mark(attribute{"foreground"}: "red') and then rendering some text there with screen.text[1][0,0] = "ABCDEFGH" - will cause the letters EFGH (col 5 and onward) to appear red. However if the characters being printed are double-width - and column 5 ends up on the continuation of a character that started on the position (4, 0) -, the mark at (5, 0) is never "seem" by the rendering mechanim.

Fixing strategy:

• Anottate in an instance attribute on terminedia.text.style.StyledSequence when a double-character was printed (it will be "seen" on the .render method - right now at line 309.) -
• Consume this attribute when checking for marks for the next character: pass it as an extra parameter to MarkMap.get_full done in the ._process_to method (the MarkMap instance is the .marks attribute in the StyledSequence instance)
• on MarkMap.get_full include the "skipped location" in the mark-search, and return it in the return.

I chose not to apply black to all the lib, bc the changes would be huge. So I took a few files, applied black, checked the changes and made some tests with (and ran some examples).

#pybr2020 #sprints

This was made in the Sprinting session of the PythonBrasi 2020 confence - Features developed in an hours long pair-programming session with Celestino Gomes - @tinogomes

Add features to GradientTransforms and Gradients - making them more flexible and easier to use.

First stage of new Text features -

This branch so far had:

- Refactor 'text.py' into directory:[V]
    - separate 'font' code into text/fonts.py [V]
    - text_planes/big text into text/planes.py (V)
    - file with text utilities for parsing/rendering text:
        - split string into units containing a single grapheme, by grouping "combining characters" together (V)
        - Refactor code to have a core to be used by  backend.print, screen.print, text.at, shape.print [V]
- Make assignment of string to shape or text area cell spread the text across as many cells as needed:[V]
    - correctly detect combining characters so that combined characters live on the same cell (V)
- create markup language for embedding context changing directives inside a single string:[V]
    - make it usable by assignment, `text[x].print` and `at` methods
    - BUG: when rendering spaces from text-planes, attributes (like background) are not updated (V):
            - fixed by sprite transparency handling implementation.[V]
    - Implement a way to "stream" rich text inside these text-plane containers [WIP]:
        - TM.text.style.StyledSequence is the class used for that [v]
        - Streamed text should allow marks for changing style (color, bg, effects, direction, position)[v]
            - accept tokens in embedded square-brackets in the string ex.: "abc[color:red]def[V]
            - Accept absolute/relative movement with "[+x,+y]" tokens embedded in the string (and work as "portals")[V]
            - allow for 'pop last parameter of this type' tokens ([/color], [/effects])[V]
            - allow for default colors with [color:default] (V) (but check default-color bug)
        - Allow a call to MLToken.parse to be passed a transformers-mapping, and us it as a source for
                transformers objects in the  markup [transformer:...] elements [wip]

- create aliased string names for the text[...] text planes [V]
- Add tests to terminedia-planes [WIP]:
    - Avoid creating a new "Text" instance on each text-plane access![V]
    - Tests for styling bases classes in progress - testing attribute changing and position

Refactor sub-pixel logic, hard coded to 1/4 block chars, and add Braille characters (which allow 2x4 subpixels per block) as an alternative high-resolution plane.

St

Effects currently cnatransfoprm ASCII to "mathematical sans-serif bold *" and "mathematical double-struck" however there are all these letter-families for mathematical symbols in unicode:

{'MATHEMATICAL BOLD': ['CAPITAL', 'SMALL', 'DIGIT'], 'MATHEMATICAL ITALIC': ['CAPITAL', 'SMALL'], 'MATHEMATICAL BOLD ITALIC': ['CAPITAL', 'SMALL'], 'MATHEMATICAL SCRIPT': ['SMALL'], 'MATHEMATICAL BOLD SCRIPT': ['CAPITAL', 'SMALL'], 'MATHEMATICAL FRAKTUR': ['CAPITAL', 'SMALL'], 'MATHEMATICAL DOUBLE-STRUCK': ['CAPITAL', 'SMALL', 'DIGIT'], 'MATHEMATICAL BOLD FRAKTUR': ['CAPITAL', 'SMALL'], 'MATHEMATICAL SANS-SERIF': ['CAPITAL', 'SMALL', 'DIGIT'], 'MATHEMATICAL SANS-SERIF BOLD': ['CAPITAL', 'SMALL', 'DIGIT'], 'MATHEMATICAL SANS-SERIF ITALIC': ['CAPITAL', 'SMALL'], 'MATHEMATICAL SANS-SERIF BOLD ITALIC': ['CAPITAL', 'SMALL'], 'MATHEMATICAL MONOSPACE': ['CAPITAL', 'SMALL', 'DIGIT']}

more:

• LATIN LETTER SMALL CAPITAL

This is mostly an FYI due to #18 and #17 being open.

The fcntl module is apparently unsuported on Windows. Attempting to run raises:

ModuleNotFoundError: No module named 'fcntl'

Didn't know this myself until some Windows tests were failing..

I just outline thse ideas in text - for steps that could take the project to actually feature "animation speed" for most effects. These were also commited in the "TODO.txt" file:

• BACKENDS:

  • "The One" optmization: (maybe sprint around Christmas 2020)
    • Benchmark complex rendering (with 2 more levels of sprites and 4+ levels of transformers + text effects / frame)
    • add consistent benchmarking as a script in tools
    • then proceed to revamp everything:
      • refactor as many pixel by pixel function calls to a way that can be pre-set to a retangular area and then used as a generator:
        • Rendering backend: should get a "shape", a rect and a file stream, and usr a method on the shape to setup pixel yielding for that area, and use a single "for" block for rendering.
        • (final backend rendering method should be contained in a single function, with no extra calls)
        • shapes:
          • have a method to setup an area, that will, in turn, setup areas in it's text planes, and sprites
          • use generator semantics with "send" to the sprites (so that transformers with any kind of transparency can have their data).
          • optimize storage to use arrays instead of lists. (no need to numpy - just arrays of 4 bytes and a fast way to interpret those as a single UTF-32 unicode codepoint string)
        • transformers:
          • benchmark to check if this is worth the effort:
          • (optional) have a decorator that could work on bytecode level to upgrade a normal function-based transformer to a generator: - insert a pos, pixel, source, ... = yield mydata; char, foreground, background, effects = pixel line at the start of the bytecode; - replace all "return" values for a "bytecode jump" to the line with the "yield". - since the transformer-generator will be garbage colector once its area-blitting is over, there is no problem that such a transformer becomes an "infinite size" generator
        • text-planes and text-style:
          • have blitted text-styles in teh text-plane have the combined (text-plane positional + string positional) Marks in place, ready to work as a generator for all "full pixels". Updating the shape will trigger the rendering for text planes
            • it is possible that this is hard to do for text-planes of more than one block per character (big-text): if that is the case, just leave big-text rendering as eager (as they work today(, and document that.
        • subpixel:
          • benchmark to csheck if "de-normalizing" the super-refactored code in there would make some difference.
          • (current code is super-geekie but requires 3-level calls to set/reset each subpixel)
          • if keeping elegance is a must, evolve a script in tools that will "glue together" the denormalized code inline.
          • (or check pymacro)
  • ^^ these optimizations should bring frame performance to a more reasonable value (10s of FPS expected. Currently 5 FPS is something just achiaveable for the most simple of renderings, just affecting an area of the screen). At this point the bottleneck should be the terminal emulator program (then check for Kitty and other terminals that intend to be fast)

A nice to have feature would be an API closer to Processing's one. Maybe we could port pyde scripts to terminedia or something similar.

References

• JS-python mapping from pyp5js;
• p5.js refence in yaml format;
• processing.py list of keywords;

Keybard handling works fine in cmd and cmder, but not on the new Windows terminal - (in an investigation a while back, I traced it to some behavior on the terminal I thought would be reversed soon - it did not happen).

• Check if the terminal app is windows terminal, and handle keyboard properly.

Current terminal backend uses the "39 SGR" Ansi sequence for 24bit color on the terminal. However, colorama wll simply strip these sequences off, resulting in no color capabilities in windows - even though windows terminal suppots 24bit color, and "cmder" supports the color sequences (and rounds the colors down to the 16 more used values).

Find a way to detect the terminal app under windows, and only trigger "colorama" if on "cmd" - the other apps work with plainANSI sequences. Round colors down to the 16 "well known codes" if on cmd or cmder.