OpenVG Spec 1.0 Errata

It can’t hurt to collect some errata in the spec…

vguArc Pseudocode (Page 147):

if arcType == VG_ARC_PIE
  MOVE_TO_ABS x, y
if arcType == VG_ARC_PIE || arcType == VG_ARC_CHORD

Should be (LINE_TO instead of MOVE_TO)

if arcType == VG_ARC_PIE
  LINE_TO_ABS x, y
if arcType == VG_ARC_PIE || arcType == VG_ARC_CHORD

That one is fixed in the most recent version.

Is that version available for public download ?

Wtf? There exist a more recent version??

Could you put it on the webserver please? That would be a big help for everyone who actually try to implement/work with OpenVG.

Btw, while we talk about errata,

The code in the ellipses-appendix is wrong as well. (page 154, 155)

Yes, a web update would be nice.
And it would also be nice if the ‘coming soon’ for the EGL 1.2 header was a little faster too (currently I’m using an the one from the Rasteroid demo).

There are lots of bugs in the spec - the path parsing function pseudo code is also wrong if I remember correctly (forgets to shift over 1 to accomodate for the REL/ABS thing, I think). Ah well…

Could you point out exactly what is wrong with the ellipse-appendix code?
I remember that it doesn’t rescale the ellipse radii when there are no circles that go through both points.

Some work has been done to correct and clarify the spec. It will be released as soon as the conformance tests are done and ratified (in the near future). I cannot post it anywhere.

Are you making an open source version or a commercial one?

@Ivo There is a macro which removes the abs/rel part of the command, but it doesn’t really have to shift it down. It depends on what is inside the processSegment() function.

Hi Espen.

Sorry, at the moment I don’t have the time to give a detailed report, but just to get started:

[li]Code on page 155: Variable pcx0 and several others haven’t been defined. Not hard to find out what they do, but it’s a typo nonetheless.[/li][/:m:1mahelib]
[li]Ellipse representation conversion on page 158, and 157. If I plug the A to F values from page 158 (build an ellipse from a matrix) into the equations of page 157 (extract radii and rotation), I’ll get recpirocal results. One of the two equation is wrong for sure. No big deal and easy to find out, but ellipses are hard enough to handle (e.g. the segment-length, transformation and a good fitting boundary box are hard to implement, unless you use brute force of course).[/li][/
[li]A minor detail, but I think in the code-sections there are unicode characters all over the place. This makes it a bit nasty to cut’n’paste the code, at least if your text editor understands unicode and treats it as such. Guess one or another numeral got converted to a unicode codepage during editing/revision. I trashed some sourcecodes more than once that way (paste unicode once, and you’ll never really get rid of it).[/*:m:1mahelib][/ul][/li]

I understand that, and it’s good to see that some people are working on the spec. It won’t help me anymore for my implementation as I’m almost finished. I’m polishing and fixing the last details.

In the spec, there are several chapters that are hard to understand. The blendmode chapter for example is switching between premultiplied and non premultiplied equations. Table 13 (Porter-Duff blend modes) assumes premultiplied input and output while Table 14 assumes non premultiplied input and output, yet the tables almost look the same. This is really confusing.

Also the Stencil Drawmode chapter could need some love. It’s hard to get a grasp what the stencil mode is suppost do do. I have to implement that tomorrow, and even after 5 reads I still only have a vague idea what it is supposd do do.

Anyway, other than those details I was pleased with the 1.0 standard. It covers most of the detail question that arise during implementation. I found more answers than I expected. That’s a very good thing.

A commercial one.


That’s be great and all, but the macro (on p53) is:
#define SEGMENT_COMMAND(command) ((command) & 0x1e)

which when used on the incoming segment, makes the command 2 times as big as it should be, causing you to go out-of-bounds on your look up for the size array (numCoords).

Needless to say, the macro should say:
#define SEGMENT_COMMAND(command) ((command) >> 1)


I’ve reported the pcx/y variable typos.

Looking at my code I see no deviation mathematically from what is in the spec. I seem to remember that some ellipse matrix inversion was necessary to get the ellipse on the Ax^2 + Cy^2 -1 = 0 form. I think this resolved the reciprocal result thing, but I can’t really remember. I’m too short on time to investigate this now too.

I don’t know about the unicode problem. Maybe it isn’t really controllable and that some word processing application just adds some of it in there.

There is some more language to the blend modes part now.

The stencil mode caused me a headache too, and I did several expansions of the formulas to premulitplied format which were occasionally wrong too, In the end it all folded into some nice case though where all divisions and such disappeared magically :slight_smile:

@Ivo good point! I reported it, so it will probably be fixed.

Also missing (if I’m not mistaken):

  • pixel order in BW_1 Format:

Inside a 8 pixel block (byte), are the left pixels stored at the LSB or MSB?

  • vgGetxxx and Errors:

When an error occured (e.g. used a wrong handle or passed illegal parameters), should vgGetxxx return valid values or not? This is unclear in the spec.

I got a new one… Not critical, just a cosmetic thing:

In the Spec, the parameters of vgModifyPathCoords is declarated as:

1.0 Spec, Page 62
void vgModifyPathCoords(VGPath dstPath,int startIndex, int numSegments,const void * pathData)

The headerfile uses VGint for startIndex and numSegments (as i would expect).