Re: [Tuxpaint-devel] Some issues related to the text tool

[Mark K. K. <mkk...@gm...>]

On Tue, Jun 03, 2008 at 02:30:37PM -0400, Albert Cahalan wrote:
> On Tue, Jun 3, 2008 at 1:06 PM, Bill Kendrick <*************> wrote:
> 
> > I think that text entered using this new tool (where text can be edited
> > later, moved around on the fly, etc.) should NOT be affected by Magic tools,
> > or painted over.  (Well, ok, if the Move tool or Mirror/Flip tools are used,
> > the X/Y coordinates of the text would change, but that's it!)
> 
> Finally we have a layer-like idea that is at least theoretically
> usable by kids and, more importantly, possible to implement.

It sounds reasonable to me, also.  Unless others have concerns,
perhaps we can discuss the implementation details (below.)

To summarize, this is going to be a new tool, separate from the text
tool.  I believe bill referred to this tool as a "label tool" so that's
the term I'll be using below.

> I'm fairly sure that is still has unusable performance on many
> machines, maybe including the OLPC XO. Crazy optimization
> (use of MMX and 3DNow! assembly) may save the day.

If there are performance concerns, at least for the initial
implementation, we can just "turn it off" at compliation time.  For most
desktops I doubt it'll be a problem with some careful design.  Handhelds
may be an issue but we won't know how much impact it will have until we
try it out.

> For usability, I think you need to have fixed lines for the text.
> Consider the problem of selecting a small letter with a big
> letter on top of it.

In a private email, Bill had an idea of "repelling labels."  At least
for the initial implementation, I think preventing labels from being
written into the same box-area of other labels will be good enough.
Moving labels can also prevent itself from overlapping with other
existing labels.  With this mechanism, we don't have to worry about
multiple layers, selecting the correct label when attempting to edit it
when multiple labels overlap, figuring out which label should be on top
of which other label, etc., but it still allows free-placement of
labels (no snapping to predetermined lines.)



HOW THE DATA SHOULD BE SAVED
============================

There are several options here.  For simplicity, I think it's best to
have two files:

  1a. One PNG file without labels.
  1b. Label data embedded into the PNG file as comments.  The data
      includes the actual string, the coordinate of the string, the font
      name of the string, the font size, and the font color.

... with all label data redrawn at open-time.

There are some consequences of saving data this way.  One consequence is
that the image file, when opened with another image application, won't
show the labels.  We would have to remedy this by having some sort of
"export" option.  Another consequence is that the image won't always
look exactly right when opened by Tux Paint on a different computer
because the other computer may not have the right fonts, and depending
on the display size the image and the fonts will need scaling which may
displace the label location.

We could store the image *with* the labels to partially take care of the
latter issue, but that does not entirely solve the issue.  For example,
storing the labels with the image allows the image to be viewable from
another computer as the image was originally drawn, but it does not
allow the label to be edited with the same font, and cause the label to
get "mangled" as soon as it is edited.

I think we simply cannot expect everything to work correctly when the
image is opened on a different computer.  Given this limitation, I think
the above option (1a + 1b) is the simplest storage mechanism.



Thoughts?

-Mark