bugGnash - The GNU Flash player - Bugs: bug #20571, Device fonts not rendered correctly

 
 

bug #20571: Device fonts not rendered correctly

Submitted by:  Udo Giacomozzi <udog>
Submitted on:  Tue 24 Jul 2007 01:34:58 PM UTC  
 
Category: coreSeverity: 5 - Blocker
Release: NoneStatus: Fixed
Privacy: PublicAssigned to: Sandro Santilli <strk>
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Thu 26 Jul 2007 04:57:35 PM UTC, comment #13:

No, this wasn't a joke. See the new bug #20597

Udo Giacomozzi <udog>
Project Member
Thu 26 Jul 2007 03:55:20 PM UTC, comment #12:

You must be kidding...

Sandro Santilli <strk>
Project MemberIn charge of this item.
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)

Udo Giacomozzi <udog>
Project Member
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.

Sandro Santilli <strk>
Project MemberIn charge of this item.
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 :)

Sandro Santilli <strk>
Project MemberIn charge of this item.
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?)

Sandro Santilli <strk>
Project MemberIn charge of this item.
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:"

Udo Giacomozzi <udog>
Project Member
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).

Sandro Santilli <strk>
Project MemberIn charge of this item.
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??).

Udo Giacomozzi <udog>
Project Member
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.

Sandro Santilli <strk>
Project MemberIn charge of this item.
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).

Sandro Santilli <strk>
Project MemberIn charge of this item.
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).

Sandro Santilli <strk>
Project MemberIn charge of this item.
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 !

Sandro Santilli <strk>
Project MemberIn charge of this item.
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.

Udo Giacomozzi <udog>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #13479:  text-accuracy-gnash.png added by udog (29KiB - image/png)
file #13480:  text-accuracy-win.png added by udog (26KiB - image/png)
file #13481:  text-accuracy.swf added by udog (10KiB - application/x-shockwave-flash)
file #13453:  devicefonts.png added by udog (89KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by strk (Posted a comment)
  • -unavailable- added by udog (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 9 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 26 Jul 2007 03:55:20 PM UTCstrkStatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
    Thu 26 Jul 2007 03:21:57 PM UTCudogAttached File-=>Added text-accuracy-gnash.png, #13479
      Attached File-=>Added text-accuracy-win.png, #13480
      Attached File-=>Added text-accuracy.swf, #13481
    Tue 24 Jul 2007 07:44:19 PM UTCstrkStatusIn Progress=>Ready For Test
    Tue 24 Jul 2007 03:57:51 PM UTCstrkCategoryNone=>core
      StatusNone=>In Progress
    Tue 24 Jul 2007 01:34:58 PM UTCudogAttached File-=>Added devicefonts.png, #13453

    Back to the top


    Powered by Savane 3.1-cleanup1