bostrom/text-to-image

Spaces not present

Closed this issue · 6 comments

ericfaris commented

Version of the library
latest

Describe the bug
It doesn't seem like spaces are being honored the way I think they would.

Here is the formatted string as it would look in Notepad++:

Table: Fog, The (Gottlieb 1979)
Author: HiRez00

Rank  User          Score      Posted
----  ----------    -------    -------------------
   1  HiRez00       629,630    01/06/2022 21:02:43
   2  StAtiC9       550,630    01/07/2022 03:43:22
   3  TastyWasps    445,510    01/08/2022 08:17:43
   4  StAtiC9       442,280    01/06/2022 05:49:50
   5  StAtiC9       387,530    01/06/2022 04:27:29

updated: 01/08/2022 14:29:59

Here is what it looks like when rendered:
image

You can see in the screenshot that the spaces are not being honored.

Any thoughts?

ericfaris commented

@bostrom Any thoughts on the above? Am I doing something wrong?

bostrom commented

@ericfaris haven't had time to look at it yet. I'll try to get back to you asap. Can you create a codesandbox that shows the issue?

ericfaris commented
ericfaris commented

@bostrom Here is the codesandbox:
https://codesandbox.io/s/broken-sea-xdi70?file=/routes/index.js

I created an endpoint that returns an image tag with the base64 string.
You can run this in the browser: https://xdi70.sse.codesandbox.io/convert

My main issue is that spaces are not being honored. If I justify with a non-space character things are formatted correctly.

bostrom commented

Thanks for the effort @ericfaris. I think this is to be expected behaviour and is even stated in the README https://github.com/bostrom/text-to-image#text-formatting-rules

Normal spaces are stripped from the beginning of paragraphs. To add leading spaces, either use tab or non-breaking space characters.

In addition to leading spaces, also additional spaces between words are squashed into one. This is because the library was made to render continuous text and handle line breaks automatically, not for preformatted tabular data like you have.

For now this is expected, not a bug, and the only workaround for your case would be to use non-breaking spaces instead of normal spaces, as you noticed yourself.

That being said, there could be a mode in which the library doesn't try to lay out the text itself, but would render it as-is. I'll consider that as a feature request 🙂

ericfaris commented