Re: [Audacity-devel] non-ascii labels

[Stuart <smc...@fr...>]

"Leland" wrote:
[...]
> > This one won't let me enter any japanese characters into a label at all.
> <snip>
> > fine except after I type the return nothing appears in the label text box.
> 
> I believe I've corrected the issues you were having.  
[...] 
> There is a weirdness though.  When the characters are displayed in Audacity,
> they are rotated from what they looked like in the IME.  Is it supposed to
> do that or is it just my system???

Japanese characters seem fine here.

[...]
> > I can enter an placeholder ascii label, open the Edit Labels dialog and
> > and change the label in there to japanese characters (*).  When I do, the
> > correct text appears in the label track.
> > (*) There is some weirdness here too.  I click in the cell for the label text.
> > The IME entry text box appears in the upper left area of my screen as
> > usual.  I type in several japanese characters and a return.  Only the first
> > character appears in the cell.  However any subsequent characters I
> > type are ok, and now, the IME entry and composition window is congruent
> > with the cell instead of in the upper left screen somewhere.
> > 
> This is an interesting one.  Here's what's happening...
[...good explanation snipped...]
> The only solution I have for you is to double click the label cell first to
> activate the edit control and then start entering text with the IME.

OK, thanks for the info.  

> > When I save the project and reopen it, I get an error messge,
> > "Error: not well formed at line 148".  Line 148 is the first label line
> > that contains japanese text.  The encoding of the .aup file appears
> > to be cp-932 (the default for my system).  I'm non-sure why the
> > non-unicode build would produce a valid utf-8 file, and the non-unicode
> > build would produce an illegal xml file (since there is no encoding
> > declaration in it, the xml reader will assume utf-8, but it is actually
> > cp-932).
> > 
> This is a definite problem and one that I'll have to ask the others for
> advice on.  Basically, we need to be able to allow and handle Unicode
> strings within the aup file.

Is it a problem to convert either unicode or double-byte encoded
strings (I'm still not sure which Audacity is using internally)
to utf-8 in the .aup file and do the reverse decoding when 
reading back in?   Alternatively, just leaving the file as it is 
now and putting an "encoding=cp-932" (or whatever the system
default encoding is) declaration in the xml would at least allow
the the file to be used on a compatibly configured system.

After rereading what I just wrote, it occured to me that I am 
assuming that you are using an xml library to do the xml
parsing.  But maybe Audacity does it's own (minimal) xml
parsing and doesn't understand encodings?

> > When I export the labels, then import them, they are imported
> > correctly.  The labels file encoding also appears to be cp-932.
> > 
> We're just getting lucky with this one since we expect the start and end
> times to be in plain ASCII and allow the label test to be in Unicode.
> 
> A couple of us were tossing around the idea of changing the label export to
> write XML files instead.  But, we'll have to hold off on that until we
> figure out how we're going to handle Unicode in the various XML files we
> create.

I posted a separate response re my take on xml label files...

> > As an aside, I also found the following to be frustrating, but maybe
> > because I don't really know what I'm doing yet...
> > 
> > If I select a section of audio, type ctrl-B, I get a label text box.
> > If I type a return, the box disappears.  If I type ctrl-B again,
> > nothing happens. (Because the the label track now has focus
> > rather than the audio track?)  I couldn't figure out how to return
> > focus to the audio track without loosing my selection (annoying
> > if it took some work to get the right selection.)
> > 
> This should be corrected also.

Yup, works fine for me now.

But I noted a another rminor problem...
1. Select a section of audio.
2. Click the Play button to listen to it.
3. Type Ctrl-B to create a new label for the selection.
4. Type some characters (can be ascii).  They are 
  ignored and not put into the label.

[...]

I noted another (new? don't think I saw in the previous download) 
issue, not sure I should mention it here, or email a bug report...

When I select a section of audio, it is marked by a gray background 
in the waveform display.  When I click Play, just that section plays,
and as it plays, a vertical line moves from the start of the grey section
to the end, indicating the point being played in realtime.

The problem is that that play-line (sorry, don't know the right 
terminology) doesn't always make it to the end of the marked
section.  The effect seems to be random, sometimes it goes
all the way to the end, sometimes it stops too soon by varying 
amounts of up to a dozen pixels or so.  The audio is ok, that 
is it plays to the end of the marked section, even when the 
play-line stops short, so it seems like only a display problem.

Apologies if you are already aware of this, I looked in Bugzilla
but didn't see anything.