Fri 06 Jul 2007 06:11:37 PM UTC, comment #24:
All the tests now work fine
|
Thu 07 Jun 2007 09:20:58 AM UTC, comment #23:
I just committed a patch that should fix this bug.
As noted in the source, I'm not that happy with the solution, because it is not based on any documentation, it's just trial-and-error. I checked various movies and they all seem to play fine now (so do the testcases).
Anyway, I simply added 2 pixels (40 TWIPS) to the glyph translation matrix.
Regarding get_left_margin(): margin was always zero in my tests. I just got different leadings (40 and 0) but that was unrelated to our problem.
Please let me know if you encounter any movie that does not render correctly.
An automated testcase would be nice, but we don't know what would be really "correct" yet...
|
Wed 06 Jun 2007 07:51:14 PM UTC, comment #22:
Seen edit_text_character_def::get_left_margin() and edit_text_character_def::get_indent() ?
(good luck!)
|
Wed 06 Jun 2007 07:39:27 PM UTC, comment #21:
It seems that Flash puts some padding in between the characters and the bounding box (the one you can see when activated).
Gnash instead starts in the upper left corner of the bounding box, which is why dynamic text is shifted towards the top left corner of the stage.
I could not yet find out the value of the padding and what controls it.
There is a TextFormat object in Flash which also includes leftMargin but it is zero by default (also in the testcase).
Resizing (not scaling) the bounding box has no effect on the position of the letters.
I had a look at that ugly format_text() function and it always starts with an offset of x/y for all text objects in my test case, so I think it works fine. Instead, we need to find an additional offset (the padding) to concatenate to the matrix.
|
Wed 06 Jun 2007 07:00:40 PM UTC, comment #20:
This is one of those cases in which automated testing helps a lot.
Unfortunately we never added one for the "old" case.
With pixel checking shouldn't be too hard.
|
Wed 06 Jun 2007 06:42:09 PM UTC, comment #19:
Still not fixed. See my new testcase. The overlaying red text (which in reality are shapes) should match the black text position.
This testcase works fine without your patch, but then the other testcase is wrong again. Strange.
Some more info in duplicate bug #20103
(file #12977)
|
Sat 12 May 2007 07:17:39 AM UTC, comment #18:
An automated testcase would prevent this from breaking again.
How about making one ?
It should check both getBounds() and actual rendered pixels.
I guess it won't be easy, but using an embedded font consisting
in all filled square glyphs would do...
|
Sun 15 Apr 2007 03:27:17 PM UTC, comment #17:
I finally approached the problem directly here.
The bug has nothing to do with matrix bugs, it's just
a wrong implementation of the align_text method most likely.
I've committed an hack that fixes all current testcases
by providing a translation matrix from within ::display.
An automated testcase would greately help here to make
sure it won't break when cleaning it up :)
|
Thu 12 Apr 2007 12:38:56 PM UTC, comment #16:
News on this. I think our matrix has bad problems with rotation
as itself. getBounds and _width fetching also have problems
when rotation comes into the picture. Martin, would you feel like
providing some testcases for matrix ? we do have a testsuite/server/MatrixTest.cpp file, but needs some more love probably.
|
Fri 05 Jan 2007 11:05:49 PM UTC, comment #15:
Udo (if you're still following) - what about trying to put the text in an arbitrary location and see if it still gets rendered inside it's box ?
I'm thinking that the "RECT" record of the DefineText character
might be constraining and that could explain the fact that
texts look identical...
|
Wed 08 Nov 2006 04:12:27 AM UTC, comment #14:
Here's some debugging from gnash (for just the rectangle)
[the working one]:
04:38:45: Matrix used for border:
04:38:45: | 0.9997 0.0000 185.8000 |
04:38:45: | 0.0000 1.0000 193.2000 |
04:38:45: Rectangle printed:
04:38:45: xmin = -2, ymin = -2, xmax = 181.45, ymax = 16.5
[the not working one]:
04:38:56: Matrix used for border:
04:38:56: | 1.0000 0.0000 138.4000 |
04:38:56: | 0.0000 1.0000 193.2000 |
04:38:56: Rectangle printed:
04:38:56: xmin = 45.35, ymin = -2, xmax = 228.75, ymax = 16.5
Note that altought the 'xmin' in the 'not working' case
seems shifted to the right, it still gets rendered correctly,
as you can visually see.
The rectangle is printed with draw_poly after a call to set_matrix (with the printed matrix as argument).
I've seen that the matrix is used by draw_poly.
Note that ~185 is the correct X position of the rectangle,
and is correctly used in both the above cases.
|
Sat 04 Nov 2006 10:07:43 AM UTC, comment #13:
I can't find any sense in this. What surprises me most is that the outline box of the text field is drawn correctly.
|
Fri 03 Nov 2006 10:21:16 PM UTC, comment #12:
Here's the differences spotted by Ming:
$ diff align-test-not-working.listswf align-test-working.listswf
2c2
< File size: 9553
---
> File size: 9558
4054c4054
< RECT: (907,-40)x(4575,330):14
---
> RECT: (-40,-40)x(3629,330):13
4066c4066
< Block length: 10
---
> Block length: 15
4078c4078,4079
< Matrix: TranslateX 2768 TranslateY 3864
---
> Matrix: ScaleX 0.999725 ScaleY 1.000000
> TranslateX 3716 TranslateY 3864
4080c4081
< Offset: 9549 (0x254d)
---
> Offset: 9554 (0x2552)
They have a different matrix in the PLACEOBJECT2 tag
(the not-working lacks a scale)
and a diffent RECT (dunno exactly what it is).
Ming is also able to decompile this into a perl script, whose
diff is:
24c24
< $s2->setBounds(4575, 330);
---
> $s2->setBounds(3629, 330);
40,42c40
< $->scaleTo(0.000000, nan);
< $->rotateTo(90.000000);
< $->moveTo(2768, 3864);
---
> $->moveTo(3716, 3864);
Apart from Ming being clearly bogus during decompilation it
shows that the working one also has some rotation or such.
Seems a misinterpretation of matrix (by both gnash and Ming, maybe).
|
Fri 03 Nov 2006 03:54:22 PM UTC, comment #11:
I attached new sample movies. The "not working" version contains the same text field copied from the other FLA file. The "working" version has been re-created from ground up using the same settings (including embedded glyphs).
I attached a IDE screenshot, which looks identical for both versions.
Can you find a difference in the .SWF file itself?
|
Thu 02 Nov 2006 08:35:33 PM UTC, comment #10:
Decompiling with 'listswf' (from Ming) shows a single PLACEOBJECT2, while I woudl have expected two...
There's one DEFINESPRITE and two DEFINEEDITTEXT.
gnash -vp shows multiple placeobjec2, so maybe we're facing
a bug in Ming too ?
gnash -vp shows:
21:30:34: SWF[9589]: tag type = 26, tag length = 9
21:30:34: place_object_2
21:30:34: depth = 1
21:30:34: char id = 2
21:30:34: mat:
21:30:34: | 1.0000 0.0000 -89.7000 |
21:30:34: | 0.0000 1.0000 -26.3500 |
21:30:34: SWF[9600]: tag type = 26, tag length = 10
21:30:34: place_object_2
21:30:34: depth = 2
21:30:34: char id = 3
21:30:34: mat:
21:30:34: | 1.0000 0.0000 -137.0500 |
21:30:34: | 0.0000 1.0000 11.9000 |
Assuming the placement of EDITTEXT as to be considered implicit, where should we get it's matrix ?
The only other hint here is a "RECT" member of them (from listswf):
RECT: (-40,-40)x(3593,330):13
RECT: (907,-40)x(4575,330):14
do these number tell you anything ?
|
Thu 02 Nov 2006 08:25:44 PM UTC, comment #9:
Can you decompile the SWF? Seems like the bogus text field is some special case (or it is not read correctly).
Will make two distinct SWF files soon...
|
Thu 02 Nov 2006 08:08:15 PM UTC, comment #8:
By some debugging this is what I find out:
21:06:29: Matrix of instance 0x8283338 :
21:06:29: | 1.0000 0.0000 157.9500 |
21:06:29: | 0.0000 1.0000 146.6500 |
21:06:29: Matrix of instance 0x8283750 :
21:06:29: | 1.0000 0.0000 110.6000 |
21:06:29: | 0.0000 1.0000 184.9000 |
The first instance is the "correct" one,
the second is the "bogus" one.
I've verified with mouse coordinate shown and
the top-right element of the matrix seems to
be the X-offset (correct in the first case,
bogus in the second case).
Next step would be understanding wheter it is
the matrix being wrong or the use of it :)
|
Wed 01 Nov 2006 11:09:41 AM UTC, comment #7:
are you talking about difference between the two textboxes
in the new sample file ?
The best way to compare is to have 2 SWF files,
one with the "working" textfield and the other with the "bogus"
one.
(comparison between align-text and aling-text2 show lots of differences)
|
Tue 31 Oct 2006 08:06:35 PM UTC, comment #6:
I attached a new sample. With my Gnash version the upper text box is rendered correctly, but the other shows the text outside the box.
Tested with AGG, don't know about other renderers.
The working text box has been created in the IDE. The other one is taken from a other FLA file (I wrote). I can find absolutely no difference between the two when looking at their properties. I also tried with a decompiler and found nothing.
Maybe someone has a better decompiler that shows very much detail? There must be something that screws up rendering.
matrix::identity seems correct as display_glyph_records() calls inst->get_world_matrix() anyway. Don't know what the parameter is for, anyway.
|
Thu 19 Oct 2006 10:02:46 AM UTC, comment #5:
I'm working on something else atm, this needs a targetted testcase to fix it more quickly (we can automatically test with MovieTester then)
|
Tue 10 Oct 2006 10:37:48 AM UTC, comment #4:
Another way to help is provide some actionscript and trace() expected values for the _x properties of the parent movieclipe and the textfield.
|
Tue 10 Oct 2006 10:35:38 AM UTC, comment #3:
Can you tell me more about the "drawing the same movie from ground up" setup ? Provide a testcase ?
|
Tue 10 Oct 2006 10:11:29 AM UTC, comment #2:
mm... check edit_text_character::display function,
matrix::identity is passed to the renderer, why ?
|
Mon 09 Oct 2006 05:15:23 PM UTC, comment #1:
Some more details about the movie:
Everything except the thin vertical line is contained inside a MovieClip.
The odd thing is, when drawing the same movie from ground up it shows correctly in Gnash. Then, when I play a bit with the text fields at a certain point the problem appears. However, the settings shown by the IDE seem to be identical.
Maybe some slight variation in the data stream that Gnash doesn't like?
|
Mon 09 Oct 2006 05:01:44 PM UTC, original submission:
Dynamic text fields are placed with the wrong X-coordinate in certain cases. I was unable to find the exact reason for this as it is hard to reproduce. However, it happened several times when creating new movies.
Tested with AGG and OpenGL backend (same results).
See the attached sample movie. The clock should be aligned to the red rectangle and shown inside the rectangle.
As you can see, the uneditable text at the right side is placed correctly.
|