Canvas:Text: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
m (legitimate use case for non-selectable text, and why we need measureText)
Line 9: Line 9:
  void pathText(in string textToDraw);
  void pathText(in string textToDraw);


Do we need measureText?
Do we need measureText? (myk: yes, so that you can resize the canvas to the size of the text, which is useful when you're using the canvas as an object representation of some text, f.e. in the microsummary editor, about which read more below)


textStyle: [http://www.w3.org/TR/CSS21/fonts.html#font-shorthand CSS 2.1 "font" shorthand], e.g. "12pt bold Helvetica".  Reading textStyle just returns the last string that was passed in.  Defaults to whatever the user's default sans serif font is (maybe serif font? what's the default for text if no font is specified?).
textStyle: [http://www.w3.org/TR/CSS21/fonts.html#font-shorthand CSS 2.1 "font" shorthand], e.g. "12pt bold Helvetica".  Reading textStyle just returns the last string that was passed in.  Defaults to whatever the user's default sans serif font is (maybe serif font? what's the default for text if no font is specified?).
Line 26: Line 26:


* vlad: nope, this is an entirely un-accessability-non-graphical-browser-friendly way to draw text.  The rationale, however, is that canvas as a whole has fallback when canvas isn't available, because even the graphics you draw may have just as much or more meaning than any text.  There are plenty of ways to get around having a text-drawing API, they're just painful and annoying, but not impossible -- which means someone will wrap it in some JS and make it easy, just possibly slow.  So if people are going to do it anyway, we may as well provide the API and make everyone happy.
* vlad: nope, this is an entirely un-accessability-non-graphical-browser-friendly way to draw text.  The rationale, however, is that canvas as a whole has fallback when canvas isn't available, because even the graphics you draw may have just as much or more meaning than any text.  There are plenty of ways to get around having a text-drawing API, they're just painful and annoying, but not impossible -- which means someone will wrap it in some JS and make it easy, just possibly slow.  So if people are going to do it anyway, we may as well provide the API and make everyone happy.
* myk: there are legitimate uses for non-selectable text.  For example, the [[Microsummaries]] support I'm building for Firefox includes a microsummary editor that lets users mix snippets of text from a summarized page with arbitrary text.<br><br>Snippet text isn't editable by the user, since it's really just a user-friendly representation of an XPath expression that pulls content from the page, so the editor needs to represent snippets as objects which can be added, deleted, or moved around, not character data that can be selected and manipulated as individual characters.<br><br>My first thought was to use SVG to draw the text, but the SVG spec says that SVG text must be selectable.  So now I'm rendering text in a hidden iframe and then drawing it onto a canvas, as roc suggests, and that works fine, but it's way overcomplicated for my simple needs.

Revision as of 11:29, 4 March 2006

Text in Canvas

The <canvas> spec currently lacks any methods for drawing text; this was done to simplify initial implementation.

API

string textStyle;
void drawText(in string textToDraw);
void pathText(in string textToDraw);

Do we need measureText? (myk: yes, so that you can resize the canvas to the size of the text, which is useful when you're using the canvas as an object representation of some text, f.e. in the microsummary editor, about which read more below)

textStyle: CSS 2.1 "font" shorthand, e.g. "12pt bold Helvetica". Reading textStyle just returns the last string that was passed in. Defaults to whatever the user's default sans serif font is (maybe serif font? what's the default for text if no font is specified?).

drawText: draws textToDraw relative to the current origin transformation matrix, and fills with the current fillStyle. The current origin is the origin of the text baseline.

pathText: adds the glyphs of the given text to the current path. They can then be stroked/filled/clipped as normal.

  • roc: You will be able to create a hidden IFRAME full of properly laid-out text with full CSS styling (plus MathML and whatever else), and draw that to a canvas --- but that won't use canvas fill/stroke.
  • vlad: Yeah, I think that's useful as well when you need to create a more complex text layout; but it seems overkill when you just want a simple string. Being able to use stroke/fill is also important (since you can do things like text with a gradient/pattern/etc).
  • roc: agree.
  • taken: In this case, user can select the texts ? IMHO, mozilla should not increase unselectable text.--Taken 01:53, 4 Mar 2006 (PST)
  • vlad: nope, this is an entirely un-accessability-non-graphical-browser-friendly way to draw text. The rationale, however, is that canvas as a whole has fallback when canvas isn't available, because even the graphics you draw may have just as much or more meaning than any text. There are plenty of ways to get around having a text-drawing API, they're just painful and annoying, but not impossible -- which means someone will wrap it in some JS and make it easy, just possibly slow. So if people are going to do it anyway, we may as well provide the API and make everyone happy.
  • myk: there are legitimate uses for non-selectable text. For example, the Microsummaries support I'm building for Firefox includes a microsummary editor that lets users mix snippets of text from a summarized page with arbitrary text.

    Snippet text isn't editable by the user, since it's really just a user-friendly representation of an XPath expression that pulls content from the page, so the editor needs to represent snippets as objects which can be added, deleted, or moved around, not character data that can be selected and manipulated as individual characters.

    My first thought was to use SVG to draw the text, but the SVG spec says that SVG text must be selectable. So now I'm rendering text in a hidden iframe and then drawing it onto a canvas, as roc suggests, and that works fine, but it's way overcomplicated for my simple needs.