[cairo] Re: Using ADD operator to prevent seams

[Robert O'Callahan]

On Tue, 22 Mar 2005 20:06:04 -0500, Owen Taylor <otaylor at redhat.com> wrote:
> On Wed, 2005-03-23 at 12:54 +1200, Robert O'Callahan wrote:
> > That is another issue. We can tweak layout logic in a few places, but
> > we can't fiddle with  layout coordinates much without breaking
> > standards or other expectations. And I don't know how to pixel-align
> > rectilinear graphics at paint time in a way that's really consistent
> > and preserves sub-pixel-size features. Any suggestions? :-)
> 
> You generally can't do it at the graphics level. But at the layout
> level, you use pixel rounded metrics and work from there. If a length
> specified in px, em or ex is non-integer, then you are doing something
> wrong.

[Starting to get off the list topic here, sorry...]

"width:7.5px;" is completely valid CSS, and people do use it. It's
actually useful for high-res devices like printers. (These are CSS
pixels, i.e., 1/96in rounded to the nearest device pixel.)

> And I'd be suprised if the CSS spec didn't allow rounding absolute (in,
> cm, pt) lengths or percentage lengths to pixels values as well.

I'm in favour of hacking the mm, in, em etc units so that authors get
pixel alignment as often as possible, but others think that's a
violation of the standard. In any case it doesn't solve all the
problems with authors using fractional units. It also doesn't solve
problems like
<div style="width:35px;">
  <img style="width:50%;"><img style="width:50%">
</div>
where the expectation is that both images will fit without line
breaking and cover the whole width of the DIV. Those gross layout
issues are actually more important to us than the appearance of 1px
join lines.

[Of course, it's fair to point out that numeric representation issues
make it impossible to 100% solve these problems. But we will do the
best we can by laying out in units of 1/60 of a CSS pixel, which is
enough for common cases --- author-specified NN.Npx, multiples of 5%,
division by 2 through 6.]

> > > Do adjoining diagonal (or curved) edges really come up enough in web
> > > pages to be worth worrying about? (Obviously, you can get whatever
> > > problems you have with SVG by embedding an SVG, but that doesn't seem
> > > to be the normal case...)
> >
> > They're not important outside of SVG, no. But we need a graphics
> > substrate that will be robust when people start doing HTML inside of
> > SVG; infrastructure for tomorrow's Web, not just today's. If someone
> > starts rotating their Web page, we don't want crazy join lines
> > suddenly appearing.
> 
> I think that's something to worry about when people find a use for
> rotated web pages.

That will be as soon as we ship a fully Cairo-based Gecko, which I
would like to see by the end of this year.

> We can always add extra backends to Cairo that
> render at some ridiculously large resolution and scale down, but
> the cost of doing such right now is pretty prohibitive. Especially
> if most of what you are drawing is text and pixel aligned boxes.

Yes, it's easy to add supersampling without affecting the rest of the
infrastructure. I'm just trying to figure out what our strategy is
going to be and get some advice (thanks!).

Rob
-- 
["Therefore, my dear friends, as you have always obeyed–not only in my
presence, but now much more in my absence–continue to work out your
salvation with fear and trembling, for it is God who works in you to will
and to act according to his good purpose." Philippians 2:12-13.]