My final plan (as my students use Snap to create educational projects) is to add a full featured vector image editor in which images created by other vector editors can be edited. I don't think this is something very high in the planned features list, is it?
For now, I would start by completing the bitmap editor, so to be able to add a text layer to costumes (note: the "write" block is not a full replacement for a costume with text, as the block writes on the pen trails layer and writings are covered by other sprites).
I never worked on the image editor so, if someone had a general plan to add the text tool to it, I would really appreciate any suggestion.
Hi! No I don't read the forum actively but I get emails when I am @-mentioned. Here I am!
I guess I could offer some pointers to working with the paint editor (I wrote it a long time ago though so I don't know how much help I could be). But I'm curious why you want to add text to the bitmap editor instead of the vector editor?
By the way, bug report in vector editor: if you select something and then resize it with corner-drag until it's all the way flat along one axis, then you can't re-inflate it.
Hi @hardmath123, nice to "see" you! and thanks for diving into this discussion
Thanks a lot. That would help a lot.
My goal is adding text to both of them. I would like to give my students an editor that will give them at least the same possibilities as Scratch's (so I guess I have also to add at least the possibility to import pictures) so that they can migrate to Snap having a fully working image editor.
As for the vector editor, I want to add at least the possibility to edit imported vector images.
I don't know how much experience you have with the Snap! codebase. To get started with the paint editor (which is in paint.js) I would recommend looking in particular at the implementation of the "set rotation center" button. Cmd-F for the string "crosshairs" to get some idea of how it works. A good first step would be to figure out how to add a new button to the toolbox (if you don't want to deal with layout issues, maybe replace the floodfill button for now).
I recommend the "set rotation center" button because it is a good example of a stateful tool that draws some extra content onto a new layer on top of the canvas. Of course you would probably want to first prompt the user for text in a pop-up, and then let them drag around the text until they are ready to commit where to place it.
I guess the idea of the extra layer linked to the rotation center button is a real good one. I aim to keep Scratch bitmap editor and Snap's as close as possibile, so that importing projects via @djdolphin's snapinator will be as straightforward as possibile.
Entering the text in a popup is a good idea, but, having a single text layer (as in Scratch), the spacing could be important, so maybe a transparent textbox can be necessary. I have then to save the extra information provided by the text so that it will be handled correctly. Any suggestion @jens and @jguille2?
Embedding fonts in the costume itself would be a terrible idea. Just include a few pre-selected fonts in Snap!, like Scratch 2.0 and 3.0. That way you can be sure those fonts are available everywhere, and you don't need to include anything in the costume except the font name.
If you don't want to do that, the next best option, at least for the bitmap editor, would be the Scratch 1.4 method. Scratch 1.4 saved a costume's text in 2 parts:
A pre-rendered bitmap, which is rendered on top of the costume's base image.
Information on the text - the actual string, font name, font size, color, and dimensions.
That way, moving the project to another computer without the font wasn't a problem, as long as you didn't edit the text. You could edit the rest of the costume, and even move the text layer, and the text bitmap would remain intact.
Using the Scratch 1.4 method here has the drawback that JS can't (easily) detect system fonts. I'd include a dropdown menu of generic CSS font families (serif, san-serif, monospace, cursive, fantasy, etc.), and let the user type in their own font names as well.
Doing something similar to the Scratch 1.4 method for vector images would be a bit more tricky. Some vector editors include black magic to convert text to a path, but I'm pretty sure you need access to the font file itself, and JS doesn't provide that. So the only realistic option to guarantee that text will look the same everywhere is to render it to a bitmap.
True, times roman is really universal, but unfortunately it is not good for digital devices. I guess I'll try to embed Arial, Helvetica and Times Roman inside the code (if I understand how that works). That should be at least initially enough.
If you're going to embed a font in the code, then you don't have to worry about it being universal.
I'm pretty sure that every browser will let you pick font category names like "serif" or "monospace" and give you a font that exists on the user's computer that's in the right category. Maybe that's all you need?
P.S. You are pushing my buttons with the dubious claim that sans serif is more readable, even on digital devices, than serif.
This is what my colleagues experts in Visual Languages (not meant as programming languages) say. And I must say that I fully support them. Serif fonts (as you can see, the font of this blog is sans serif) are really annoying on a computer screen. But a printed page written in sans serif is really bad. So, yes, sans serif is the correct choice for a computer screen, while serif is the right choice for a book.
Yes, this is what John Maloney told me when I complained that when editing the costumes of the sprites in my students' projects their font often suddenly changed even if I could run the project with the correct font if it wasn't installed in my PC.
I agree. Do you think Snapintor could be updated so to be able to edit in the updated Snap image editor texts in costumes imported from Scratch?
I'm not going to move to vector until the bitmap editor is complete. So I will try to understand what you are saying here when I'm done
Making it as similar as possible to Scratch 1.4 would basically mean copying all the relevant text properties. But don't worry about making it easy for Snapinator. What was best for Scratch in 2009 probably isn't what's best for Snap! in 2020, and I'll make it convert to whatever you implement.
And if it would help, here's how Snapinator handles Scratch 1.4 text: