[cairo] Minutes from conference call 2004-10-09

[Carl Worth]

Here are the minutes from today's conference call. We tried to stop
after one hour, but there was some juicy technical stuff on the agenda
that we hadn't gotten to yet, (ie. non-antialiased graphics and
snapping). We agreed to press on and wrapped up after a second hour--my
notes are much sketchier on this second half. Any errors or omissions
are entirely my fault.

I'm interested in feedback on the conference call process from
participants and non-participants. Was this a useful thing to do? Should
we do it again? Soon? Regularly?

I anticipate there may be follow-ups to this message on various
topics. Please modify the subject line as appropriate.

Thanks,

-Carl

PS. These minutes ended up being perhaps more verbose than
necessary. But I do want to make sure people who were not able to call
still feel aware of what discussion is going on. Please let me know what
you think.

Minutes from cairo conference call 2004-10-09

Attendees (IRC nicks where known)
---------------------------------
Peter Bartok (pdb)
Øyvind Kolås (pippin)
Ravindra Kumar (rkumar)
Jordi Mas
Keith Packard (keithp)
Stuart Parmenter (pavlov)
Tim Rowley (tor)
Bill Spitzak
Owen Taylor (otaylor)
Carl Worth (cworth)

Agenda
------
Let's start with status stuff (which should be quick), then move on to
requirements, technical discussions and end with 1.0 plans

Status:
	* backend status
	* "real" printing support
	* documentation
	* Front-end requirements

Technical Topics:
	* non-AA graphics
	* Pixel alignment mechanisms

Release Schedule:
	* 1.0 release schedule

We've got an hour; let's try to avoid getting stuck in one area for too 
long.

Minutes
-------
> Status:
> 	* backend status

Render and image backends are the original backends and are largely
unchanged. The glitz backend was added later and made to match the
existing backend interface. The backend interface should perhaps change
more, (see David's recent proposal to the list).

The current PostScript backend is really just a wrapper around the image
backend. It's not expected to have long-term viability in this form.

Stuart has had a Win32 backend in progress for a while now, but it
hasn't gotten pushed into CVS yet. It uses GDI+. It is missing support
for a couple of the composite operators and he hasn't had time to
implement GDI or image-backend fallbacks yet. There is partial font
support. Things are not yet integrated into the cairo build system.

The plan is to get this pushed into CVS as soon as possible. Interested
people will fix the build issues, (Owen volunteered Tim?).

Stuart reports that there are two Quartz backends in progress. One was
done by someone for Mozilla, and we haven't seen anything of that
yet. The other was recently posted to the list.

Stuart volunteered to get these two developers in touch with each
other. We'd like to have some code land in CVS soon for this as well.

Carl plans to work on a real PDF backend.

> 	* "real" printing support

The plan is to first construct a PDF backend. From there, we can write
custom PDF-to-PostScript conversion using the limited subset of PDF that
we know we generate. Just plain PDF might be suitable for some systems,
but a strong dependency on GhostScript seems like a bad idea.

There was some discussion on how to support various parameters for the
print output, such as paper sizes, and whether the cairo API needed to
change for this. The consensus was that cairo should focus on the
drawing, and the application should coordinate any communication with
the print system to discover and set whatever options are available.

There was also some discussion about how to get other metadata into the
PDF output. The consensus was that cairo focus on being a graphics
library and not a full-featured PDF-generation library. However, it
seems that at the very least, the text in the PDF output from cairo
should be selectable. Owen reports that there are multiple mechanisms
for this in PDF with varying features, complexity, and support in common
tools. More investigation will be needed to figure out how cairo might
need to be augmented to support this, (ie. maybe a call that says:
"Here's some text and it will appear within this rectangle", or
similar).

> 	* documentation

We definitely need a good reference manual and a tutorial to start
with. Maybe someone would be interested in pursuing a published cairo
book?

Owen highly recommends inline documentation and reminds us that internal
documentation is also important. The backend interface is one internal
portion that everyone agreed needs to be documented.

> 	* Front-end requirements

The question was raised: "Given the current cairo API and the ways in
which people want to use it, what's missing?"

One feature suggested by those with experience with mozilla/SVG is
geometric operations on path objects. Carl mentioned that this would be
easier to support if a geometric result was not necessary, but rather
just the ability to do point-based hit testing (eg. inside or
outside). Tim thinks that would be sufficient.

An old issue from the mailing list was raised regarding eliminating
compositing operators that can change pixels where alpha == 0. The idea
is that the internal compositing can be simplified if there are
guarantees that regions outside the path are unchanged. There wasn't
consensus on how this change would look, and it was decided to take the
issue to the mailing list.

For reference, the compositing operators in cairo are the Porter/Duff
operators described in their paper, which can be found here:

	http://keithp.com/~keithp/porterduff/

Another request was made for rendering with bit depths higher than
8-bits per color channel as well as support for colorspace
management. Keith explained the plan is to use the existing API (which
already has floating-point color values) and to make a new
floating-point backend with a signed sRGB color space. This should
support all of CIE-XYZ.

Another suggestion was made to provide a call to directly set 8-bit
color values. This could cause some confusion regarding pre-multiplied
vs. non-premultiplied alpha if alpha and RGB were in the same call, but
might be reasonable otherwise.

[1 hour mark. Discussion about stopping vs. continuing]

> Technical Topics:
> 	* non-AA graphics

Some people need to draw non-antialiased graphics---primarily for
emulating other graphics systems in something close to a pixel-perfect
fashion. There was general agreement among the attendees that the
antialiased graphics look better, but also an acknowledgment that there
exist users that have been trained otherwise. Additionally, if the
graphics must be presented on the same display as other non-antialiased
graphics it may be preferable to match.

There was some discussion of the technical work that would be needed to
make this work. The backends already provide support for 1-bit masks, it
would just need to be hooked up. Additionally, the regular polygon for
the pen would need to be replaced with John Hobby's "pen polygons". This
would preserve consistent apparent line widths for pens of any
size. Keith says that since we're already performing the convolution of
polygonal paths, that adding the "pen polygon" is as simple as adding a
table of precomputed polygons. Hobby's paper on the subject is available
here:

	http://cm.bell-labs.com/cm/cs/doc/87/2-04.ps.gz
	John D. Hobby, Rasterizing Curves of Constant Width, JACM 36(2), 1989.

Carl accepted an action item to investigate doing non-antialiased
graphics in cairo and posting some results.

The question was raised if this would be sufficient without also solving
the problem that raster ops are not available in cairo. [Unfortunately,
I missed the answer to this question.]

> 	* Pixel alignment mechanisms

The ability to line up paths with device pixel boundaries is useful
whether or not antialiasing is being performed. And where it's not
necessary to perform emulation of a non-antialiased graphics system, this
alignment may be sufficient to satisfy some users who are struggling
with getting sharp 1-pixel lines with cairo.

The primary difficulty is that many users want to be able to draw
horizontal/vertical lines exactly 1-pixel wide. It turns out that this
can't be done by default in cairo using integer endpoints for the
line. There also isn't a way to fix this by changing the default matrix,
as then the same problem crops up for fills instead of strokes. Owen
pointed out that an advantage of the current model is that it is very
predictable and it's easy to know what's going on if you have graph
paper and know the rules (eg. integer coordinates map by default to
positions half-way between pixels).

The consensus was that the "1-pixel line problem" is largely an issue of
insufficient documentation. Keith points out that the default line width
of 2.0 was intended to prevent users from seeing this by default. But
Carl says that a lot of users email with this as their first
problem. Users must be tuning down the line width and are surprised that
the line only becomes fainter and not thinner (in terms of number of
pixels).

Keith jokingly proposed to switch the API to specify a pen radius rather
than a line width. Then the default line width of 2 would become a
default radius of 1. That might help trigger understanding in users that
switching to a radius of 0.5 might also require adjusting the endpoints.

Beyond snapping horizontal and vertical strokes, issues were discussed
regarding snapping fill coordinates (including extremal points of
curves). It was pointed out that ideal snapping really depends on
scene-level information and as such really belongs at the application
level above cairo.

> Release Schedule:
> 	* 1.0 release schedule

Deferred until a later discussion as the time was far spent.

Suggested items for a future agenda
-----------------------------------
* Default transformation matrix.

Action items from today
-----------------------
* Stuart to commit win32 backend.

* Stuart to get both Quartz backend people talking so code can get
  committed.

* Carl to experiment with non-antialiased rendering in cairo.