Thu 26 Jul 2007 04:57:35 PM UTC, comment #13:
No, this wasn't a joke. See the new bug #20597
|
Thu 26 Jul 2007 03:55:20 PM UTC, comment #12:
You must be kidding...
|
Thu 26 Jul 2007 03:21:57 PM UTC, comment #11:
Yes, much better now!
Now, a not so critical problem remains. Device fonts look different compared to their embedded versions. Note not even the proprietary player is correct in this regard, but device font rendering done by Gnash looks like if the wrong font style (normal instead of bold) is rendered.
The attached movie shows two dynamic text fields. One uses device font "Arial", the other has an embedded font. The red overlay is a shape generated using the IDE.
The embedded version is rendered perfectly by both Gnash and PP. The device font version differs much more.
(file #13479, file #13480, file #13481)
|
Tue 24 Jul 2007 09:59:17 PM UTC, comment #10:
FYI: I also committed a patch to make gnash as much compatible to the pp as possible. Please test.
|
Tue 24 Jul 2007 07:44:19 PM UTC, comment #9:
I split the gnash::font class glyph set into 'device' and 'embed' subsets, and updated all interfaces to specify which one to use.
Your specific testcase is fixed now. Please send more :)
|
Tue 24 Jul 2007 05:08:21 PM UTC, comment #8:
I'm working on support for the .embedFonts member of TextField, which I get should trigger use of embedded vs. device glyphs in the same font.
What I'm stuck on now is how to initialize that member (ie: what makes them device or embedded when they are defined in the SWF?)
|
Tue 24 Jul 2007 05:02:45 PM UTC, comment #7:
I see. They probably come from the static labels:
"No cxform:"
"33% alpha:"
"tint cxform:"
"tint + alpha:"
|
Tue 24 Jul 2007 04:50:27 PM UTC, comment #6:
Your SWF definitely contains a few embedded fonts for the Arial one.
Check with listswf (from Ming) or with gnash -vp (with current head).
|
Tue 24 Jul 2007 04:16:36 PM UTC, comment #5:
Makes sense, but there should no glyph be embedded for the "Arial" font. The embedded font input field is configured to embed the basic latin (a-z, A-Z, 0-9) and puntuation (summing up to a total of 114 glyphs) of the non-standard font "Corbel".
So it's strange Gnash mixes up these two fonts (or perhaps Flash embeds too many glyphs??).
|
Tue 24 Jul 2007 03:57:51 PM UTC, comment #4:
Good info for a small refactoring:
< strk> so the same font must be able to contain both embedded and device, and to be requested which one to use (and never mix them up) - right ?
< davr> a single textfield would never contain both embedded and device, but the same font on different textfields, yes
So the bug in Gnash is that we mix embedded and device fonts into a single TextField.
|
Tue 24 Jul 2007 03:38:38 PM UTC, comment #3:
This is interesting :
font Arial - get_glyph_index(w - 119) called
Advance value for glyph 'w' is 837.5 (horiAdvance:1675, scale:0.5)
get_glyph_index(119) returning 19
font Arial - get_advance(19) called
return advance from advance table (837.5)
font Arial - get_glyph_index(h - 104) called
get_glyph_index(104) returning 9
font Arial - get_advance(9) called
return advance from advance table (0)
As you can see, the 'w' character did not have an SWF-defined glyph, so Gnash looked that up from the device (Freetype) and computed correct advance.
On the other hand, the 'h' character WAS DEFINED from within the SWF, which supposedly also provide an advance value, which in this case was zero (has_layout is false).
Now, what do you think we should do in this case ?
By not having a layout info, we end up with a set of glyphs (shape_characters) but no corresponding advance, how should we compute the advance then ? Would you provide a testcase for just this with embedded fonts (as it's an embedded-fonts problem, not a device fonts one).
|
Tue 24 Jul 2007 03:22:31 PM UTC, comment #2:
It seems the missing lookups are due to the fact that the used font
already has some glyphs, including the 'h', which is missing in the report below. How are you defining that font ?
Are you changing name at runtime maybe ? (we don't cleanup
the existing glyphs in that case).
|
Tue 24 Jul 2007 03:00:47 PM UTC, comment #1:
Here's some info about advance value:
EM square for font 'Arial' is 2048, scale is thus 0.5
Advance value for glyph 'w' is 837.5 (horiAdvance:1675, scale:0.5)
Advance value for glyph 'e' is 630 (horiAdvance:1260, scale:0.5)
Advance value for glyph 'v' is 606 (horiAdvance:1212, scale:0.5)
Advance value for glyph '(' is 399.5 (horiAdvance:799, scale:0.5)
Advance value for glyph 'd' is 650 (horiAdvance:1300, scale:0.5)
Advance value for glyph ')' is 399.5 (horiAdvance:799, scale:0.5)
Advance value for glyph 'b' is 650 (horiAdvance:1300, scale:0.5)
Advance value for glyph 's' is 533.5 (horiAdvance:1067, scale:0.5)
It's interesting to note that some characters are not looked up for
at all !
|
Tue 24 Jul 2007 01:34:58 PM UTC, original submission:
Device fonts are not rendered correctly. Some letters appear above others, looks like the space of some characters to the next one is zero.
Embedded fonts work fine.
See attachment (used font is "Arial").
I'd say this is a BLOCKER since we advertise device fonts a new feature for the upcoming release and it's pretty useless if it does not render them correctly.
|