Text entry mode should reflect the finished text positioning and scale

[tarngerine]

Reading some past issues I think folks have raised jarring UX when editing a text, committing that change, and seeing that text resize/resposition to fit into the bounding box.

To be clear: i am fine with the "fit in the box" behavior when commiting a change.

However, I wonder if the editing/entry mode can reflect WYSIWIG so it's not so jarring. Most text entry tools function this way, from macOS's preview, to Cleanshot, to Figma, or tldraw — the rendering of text during editing should === rendering of text after editing.

Thanks~

[ailon]

There are a couple of things at play here.

First, purely technically the text is rendered and edited using two different technologies (SVG and HTML) so it would likely never be a perfect WYSIWYG. Though, I guess I could try getting closer. After all it was just a textbox to enter text until some version (much closer to WYSIWYG now ;) Having said that, if there's too much text and it gets downsized while editing to the point of illegibility it's easy to resize the rendered box, but I'd have to support resizing the editing box as well. This opens another can of worms.

Second, the markers can be rotated. It's unclear what to do then. I definitely don't want to force people to edit the text upside down. And if it's not upside down it wouldn't be really WYSIWYG anyway.

[tarngerine]

Yea it’s tricky! I built the same style of HTML/SVG text syncing for felt.com and also I know tldraw.com has the same approach. Neither of those resize the text down based on a bounding box though so maybe it’s a bit trickier here for markerjs2

In most wysiwig products like illustrator or figma if you flip the text and edit it, the editor is flipped. Personally I think that’s acceptable since the user opted to rotate the text anyway, they probably have some specific layout requirement and previewing that as they write is better than edit, commit, edit again because it jumped to another place.

Thanks for the context though! For our use case we definitely need wysiwig (use case similar to cleanshot for quick high polish annotations where the audience cares about design and accuracy) so we might have to just fork TextMarker for now :3 On Aug 11, 2022, 1:44 AM -0500, Alan Mendelevich @.***>, wrote:

There are a couple of things at play here. First, purely technically the text is rendered and edited using two different technologies (SVG and HTML) so it would likely never be a perfect WYSIWYG. Though, I guess I could try getting closer. After all it was just a textbox to enter text until some version (much closer to WYSIWYG now ;) Having said that, if there's too much text and it gets downsized while editing to the point of illegibility it's easy to resize the rendered box, but I'd have to support resizing the editing box as well. This opens another can of worms. Second, the markers can be rotated. It's unclear what to do then. I definitely don't want to force people to edit the text upside down. And if it's not upside down it wouldn't be really WYSIWYG anyway. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>