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

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

There are quite a few threads, both private and public, regarding the
text tool enhancement.  If it's okay with everyone, I'd like to
consolidate them into this single public thread to reduce redundancy.

To give you some background information, Arunodai is enhancing the Tux
Paint text tool for Google Summer of Code.  I am assigned as his mentor.
The requirement is that the text tool, once used to enter text into the
drawing area, can be edited at a later time.  The details are up for
discussion, which will benefit from this public discussion.

First, let me respond to the public thread on this mailing list, to
which Albert responded last as follows:

On Sat, May 31, 2008 at 04:52:42AM -0400, Albert Cahalan wrote:
> On Sat, May 31, 2008 at 2:17 AM, vudem arun wrote:
> 
> > About being able to select the text long long time after the text has
> > been entered.  We could save the data in the list where information about the
> > text is present. Now when open is used and the corresponding drawing
> > along with the list informations gets loaded. Thus it can be edited.
> > but with support for system dialogs coming up and renaming of files
> > being a possibility this will not be good enough. Is there someway in
> > which we ca handle this problem.
> 
> There is no "undo" support for freshly loaded files.
> The history is not saved with the image.

Albert's statement is technically correct, but I think he may have
misunderstood Arunodai's email.  Arunodai is specifically referring to
the mechanism of storing the text data, so the text data can be edited
later, not for undo operations.

> > The file naming convention could be
> > kept simple like all the files related to xxx.png could be
> > xxx-lyyy.png where yyy would be the layer number. Can we work around
> > this so that the same filename cannot be used in a different
> > directory. All the other files could b e saved in the current tuxpaint
> > saving directory except the whole drawing.
> 
> Don't go there. (big mess)

I agree creating several files for each drawing will be messy, but I
think the alternatives aren't much better.  The text data, if we want
the text to be editable across saving, will need to be saved.
Arunodai's proposal is to create one file per layer, where multiple
layers are required to store all the texts at different layers.  The
alternatives are:

  1. Choose a file format that can support layers so that only a single
     file is created.  MNG, XCF, etc.

  2. Save all non-text data into a single file in a proprietary format,
     so only two files are created.

  3. Don't do layers.  When the image is saved, it's saved in a single
     layer, with no further editing of text upon re-opening of the file.

  4. Save all extra data into PNG's meta-data area.

I would like #3, but Bill wants the text editable a long time after it
is entered.  Barring #3, other options will take long time to implement
correctly.  I only see multi-file format as the only other option.
Please suggest other options if there are other viable options.

I would like to see either a multi-file option or not doing layers at
all, at least for the initial implementation.  Perhaps #1 is the best
option in the long-term, but it's not practical for the GSoC timeframe.

> > I am also thinking of ways in which we change the background image
> > when text is selected. The problem that we face here is as follows:
> > Suppose the text is entered, and smudge is applied in the area of the
> > text.
> 
> The text is now uneditable.

Again, Bill wants the text editable a long time after it is entered.  I
think Albert's idea gives a cleaner solution, though, at least for the
first phase of the implementation.

> No layers! It's too slow, it eats too much memory,
> it makes the UI complicated, and it makes the code
> harder to understand.
...
> > Another issue I was thinking was about drawing above the text. How do
> > we handle that situation. Suppose the text is partially covered and a
> > brush is used to draw an top of the text.
> 
> That text is now just part of the image. Any notion of
> it being text is long gone.
...
> "large scale" is an understatement. This is massive.

All these are valid concerns.  Perhaps the thing to do here, given the
complications, is to allow text to be edited until a specific point
(e.g., until the text tool is de-selected) for the initial
implementation.  That way we can defer the file storage and magic-tool
interaction issues for another time.  For the initial impelmentation, we
can work out the interface and data structures.

My biggest concern, as the mentor for this project, is that I think the
file storage and magic-tool interaction issues are difficult problems
that we won't have time to work out thoroughly during the GSoC period.
Bill/Arunodai - would you guys be okay with this for now?  The other
features can be implemented as time allows, whether it be during GSoC or
following it.

There are several more issues I'd like to discuss that were raised in
private emails, but if Bill/Arunodai is okay with the above proposal I
think the remaining discussions can be deferred to a later time, with
the remaining GSoC time concentrated on the initial implementation.

-Mark