Re: [whatwg] <canvas> feedback

> > > > and it is not possible to resolve font sizes in physical length
> > > > units unless the document is associated with a view.
> > >
> > > Why not? The canvas has a pixel density (currently always 1:1), no?
> >
> > 1:1 is not a physical pixel density. To resolve a font size that is
> > specified in physical units (e.g. millimeters or inches) you need
> > something like a DPI value, which requires information about the output
> > device.
> No, not any more. CSS "physical" units are defined as mapping to CSS
> pixels at 96 CSS pixels per CSS inch, and canvas is defined as mapping CSS
> pixels to canvas coordinate space units at one CSS pixel per coordinate
> space unit. As far as I know, all browsers do this now.

Right... So I think there is a bug in Blink then. Thanks.

> > > > My 2 cents: specifying fallback behaviors for all use cases that are
> > > > context dependent could be tedious and I have yet to see a
> > > > real-world use case that requires being able to paint a canvas in a
> > > > frame-less document. Therefore, I think the spec should clearly
> > > > state <canvas> elements that are in a document without a browsing
> > > > context are unusable. Not sure what the exact behavior should be
> > > > though.  Should an exception be thrown upon trying to use the
> > > > rendering context? Perhaps canvas draws should fail silently, and
> > > > using the canvas as an image source should give transparent black
> > > > pixels?
> > >
> > > As far as I can tell, this is all already specified, and it just gets
> > > treated like a normal canvas.
> >
> > Agreed. The fallback behavior is specified. But is it good enough? There
> > will be discrepancies, sometimes large ones, between text rendered with
> > and without a browsing context.
> I don't think there should be any discrepancies.

One major discrepancy I noticed is that web font resolution fails but I
don't think that is due to lack of a browsing context per se. It is more
precisely due to the fact that we don't compute style on documents that are
not displayed (web fonts are defined in CSS).

> > > Instead, we should use adaptive algorithms, for example always using
> > > the prettiest algorithms unless we find that frame rate is suffering,
> > > and then stepping down to faster algorithms.
> >
> > Such an adaptive algorithm implies making some kind of weighted decision
> > to chose a reasonable compromise between quality and performance.
> > Sounds like the perfect place to use a hint.
> If we really need a hint. But do we? Do we have data showing that adaptive
> algorithms can't do a good job without a hint?

Fair enough. Will give it a try.

> On Mon, 7 Apr 2014, Justin Novosad wrote:
> >
> > Dashing is one thing that would be affected.  I think some
> > implementations are currently in a non-compliant state probably because
> > the line dashing feature was added recently.  Back when strokeRect was
> > originally implemented, we could get away with blindly normalizing
> > rectangles because there was no impact on the rendering result.  The
> > other thing that is affected is fill rule application.  For example, if
> > you have a path that contains two intersecting rectangles and you are
> > filling in with the nonzero rule.  If one of the two rectangles is
> > flipped, then the intersection region should be unfilled.  If the
> > rectangles are "normalized" internally by the implementation, then you
> > will get the wrong (non spec compliant) result.
> I've added "in that order" to rect().


> I couldn't find the original reason for strokeRect() only drawing one line
> in the one-dimensional case, though it dates back to 2007 at least.

That speaks for itself: If no one has complained about that since 2007...

> I haven't changed rect() to do that too.

Good. I think it is best for rect to not optimize to a line because that
would affect filling in an undesirable way and it would affect the start
point of the next sub-path.  That being said, it is probably safe to
optimize it to two lines, but that does not have to be detailed in the spec
since it is an implementation optimization that has no effect on the
rendered result.

> On Sun, 6 Apr 2014, Dirk Schulze wrote:
> >
> > The spec says that the object TextMetrics[1] must return font and actual
> > text metrics. All things require information from the font or the font
> > system. In many cases either font or font system just do not provide
> > these information.
> Which cases? The information is needed for text layout purposes; if the
> browser can't get the information, how is it conforming to CSS?

It conforms by applying approximation rules (or guesses?) that derive the
missing metrics from the ones that are available.  It's ugly, but it kinda

Received on Tuesday, 29 April 2014 23:36:41 UTC