Re: [Gnash-dev] shape_character_def fill/line styles

[strk]

On Sun, May 20, 2007 at 12:08:06PM +0200, Udo Giacomozzi wrote:

> s> What I know is that it's not only easy, but it's actually happening that 
> the indexes
> s> end up referring to unexistend elements of the vectors.
> 
> What causes this? I guess the root problem is another one..

The problem was using a fill style index as an offset
to the corresponding *EMPTY* shape_character_def style vector.
It's intrinsic in the current model, as style change is read
for glyphs (usually always 1) but no style info are present
in the SWF.
Agg was blindly trusting the caller to have provided consistent
data instead.
When I tried to use a style offset of '0' AGG simply did NOT
render the glyphs (ie: transparent fill?).

So my solution was providing a dummy fill style entry
in the shape_character_def when reading glyphs, and warning
about malformed SWF when any other index is used for style
change (it seems 1 is what is required to be there by specs).

> s> When trying to ensure consistency, I found that the *inconsistency* is 
> needed
> s> for glyphs. When parsing a DEFINEFONT or DEFINEFONT2 tag, we're going to 
> read
> s> shape definitions that contain a left-fill offset of 1 (first element of
> s> the array), but we never create that array.
> 
> Hmm, *probably* because glyphs always use solid fills (ie. don't use
> real fill styles).

Probably. Still we didn't create such a solid fill before, while we contained
paths pointing to these phantom elements...

> s> Hackish handling of this is in the renderer classes, that create an ad-hoc 
> style
> s> when dealing with glyphs.
> 
> Remember that the fill color of the glyph is also defined ad-hoc.
> draw_glyph() has a "color" parameter..

I wonder if we can add the "color" parameter to the dummy fill style and remove
that parameter from the draw_glyph() call. But I'm afraid we can't as glyphs
can probably be rendered in different colors based on instances. Maybe
the dummy style would be a solid white fill and the draw_glyph() should take
a color transform or so...

> s> Unfortunately, discarding the fill and line style indexes in these cases 
> (which is:
> s> whenever they refer to an unknown/unexistent element) breaks the 
> rendering: glyhps
> s> are no more shown.
> 
> AGG uses a fully transparent "color" for inexistent fill styles. Just
> to avoid critical errors. Maybe it's not a clean design (using
> hardcoded fill style IDs) but I see no real problem in this.

You mean for fill style indexes == 0 here, right ?

> Before fixing anything we'd need to understand the problem first. Why
> should there be a problem with fill style IDs (instead of pointers)?

There would be a problem if it's not clear what do the indexes point to.
There would be problems if pre and post conditions are not defined.

> More interesting would be to know why referenced fill styles stop
> existing at some point (this is what I understood from your mail).

No, you didn't understand. Or *I* didn't.
Anyway, what I'm saying is that the referenced fill style *never* existed.
The shape_character_def::read is called with the parameter 'with_style'
== false (which is do not read any style info).

> After all, there is nothing that changes fill styles.

Nothing created it for glyphs.
See my commit of 2007-05-14 for shape_character_def.cpp, with
commit log:

        * server/parser/shape_character_def.cpp (read): when parsing
          DEFINEFONT tags provide a dummy solid white fill style to
          act as a placeholder for consistency checking.

--strk;