<div dir="ltr"><div><br></div>I updated the test scene at<br><div><br><a href="http://andreasplesch.github.io/x3dom/x3dom_text/driver_x3dom.xhtml" target="_blank">http://andreasplesch.github.io/x3dom/x3dom_text/driver_x3dom.xhtml</a><br><br></div><div>with an additional button at the bottom center which toggles between BEGIN, MIDDLE, and END major positioning of the text as envisioned.<br><br></div><div>In order to have compatibility a fourth state would be probably needed: "DEFAULT", "ZERO", "NONE" (?). It would be the default value and replicate the current behaviour (by setting the additional offset along the major axis (x-axis) to 0).<br><br><br></div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 6, 2015 at 5:50 PM, Andreas Plesch <span dir="ltr"><<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Don, let me update <br><br><a href="http://andreasplesch.github.io/x3dom/x3dom_text/driver_x3dom.xhtml" target="_blank">http://andreasplesch.github.io/x3dom/x3dom_text/driver_x3dom.xhtml</a><br><br></div>with a button that will center the text box horizontally at the origin independent of major alignment in order to illustrate what I tried to describe. This will be for demonstration only, eg. only work for this example, since I do not know how to determine the final width of the rendered text box with x3d only methods.<br><br></div><div>Thinking about absolute major positioning as a third alignment argument I think one can define again the three cases: MIDDLE would be what I had in mind. BEGIN would align the left text box margin with the origin, and END the right margin - independent of the major alignment. The existing major alignments then imply a certain absolute major positioning if not otherwise specified.<br></div><div>So "BEGIN BEGIN" implies BEGIN, but "END BEGIN" implies END absolute major positioning.<br></div><div>With a third argument one could specify "BEGIN BEGIN END" to mean that left aligned text is positioned such that the right margin of the text box is at the origin, eg. the text would be left of the Y axis. This is useful for a label which is to appear left of some object:<br></div><div> <br></div><br><div><font face="monospace,monospace">left aligned line 1 |<br></font></div><div><font face="monospace,monospace">line 2 is here | <br></font></div><div><font face="monospace,monospace">line 3 could be longer|<br></font></div><div><font face="monospace,monospace"> x=0<br></font></div><div><br></div><div>"BEGIN BEGIN MIDDLE" would center left aligned text at the Y axis.<br><br><div><font face="monospace,monospace">left align</font><font face="monospace,monospace"><font face="monospace,monospace">|</font>ed line 1<br></font></div><div><font face="monospace,monospace">line 2 i</font><font face="monospace,monospace">s </font><font face="monospace,monospace"><font face="monospace,monospace"><font face="monospace,monospace">|</font></font>here <br></font></div><div><font face="monospace,monospace">line</font><font face="monospace,monospace"><font face="monospace,monospace"> </font>3 at </font><font face="monospace,monospace"><font face="monospace,monospace"><font face="monospace,monospace"><font face="monospace,monospace">|</font></font></font>the end</font><font face="monospace,monospace"><font face="monospace,monospace"><font face="monospace,monospace"></font></font> </font></div><div><font face="monospace,monospace"> x=0<br></font></div><br></div><div>I am pretty sure this idea can be mapped to right to left or/and vertical text as well.<br></div><div>Although it sounds complicated I think a third alignment argument for absolute major (horizontal) positioning of the text box would be quite useful.<br></div><div><br></div><div>The main use case for the text node currently seems to be short descriptions or labels for which it works well. It looks like the text node was designed for this usage. Simple text formatting within a node would be very useful but probably not compatible with the separation of text from fontstyle.<br><br></div><div>Another use case may be longer text or prosa although a 3d environment usually would not be the first choice to present such. For such use specification by delegation or reference to another standard seems to me most reasonable. HTML(+CSS?) might work given a provided "window" size but then requires the x3d browser to include a full html renderer (web browser). <br><br>PdfTexture may be another option which would have the advantage of good reproducibility.<br><br></div><div>BTW, font size is well known to be a fuzzy concept. It is entirely up to the font designer (font data file) how large a glyph will appear when say size 12pt is requested. For the web, there are attempts to at least be able to find out about various size metrics (<a href="https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics" target="_blank">https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics</a>) but they are not well supported.<br><br></div><div>Extruded text is a standard 3d graphics feature which is missing. Perhaps there is a way to integrate it into Extrusion ? Have an additional SFNode Text field for Extrusion which takes precedence over crossSection if not null ?<br>Practically speaking, for x3dom extruded 3d text would be a new feature which requires vectorization of fonts which has some performance implications. Cobweb does vectorize fonts using a third party library. Performance is ok for smaller texts. <br></div><div><br></div><div>some ideas,<br><br></div><div>Andreas<br></div><div><br></div><div><div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 6, 2015 at 9:50 AM, Don Brutzman <span dir="ltr"><<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks for the careful thinking Andreas.<br>
<br>
Of note is that FontStyle specification is carefully designed to handle various text directions in support of internationalization (i18n). This is really important not to break.<br>
<br>
Something else that seems to vary among implementations is that font size can vary for different font types. Further, aside from X3DOM use of Webfonts, there seems to be little browser support for alternate fonts.<br>
<br>
Coming up with an example that shows your case below, perhaps in comparison to other FontStyle use cases, may help define the goals more precisely.<br>
<br>
Another awkward part of Text in X3D is that things like italics, bold, marked-up paragraphs etc. have to be done with separate nodes... makes it quite hard to compose a typical HTML paragraph.<br>
<br>
All this probably deserves further investigation:<br>
<br>
a. The X3D Text component is pretty rich, so new extensibility can be considered using existing capabilities. Perhaps we might design some kind of TextLayout prototype that allows more flexibility in markup while producing the corresponding X3D v3.3 Text/FontStyle/Transform combinations needed to render it.<br>
<br>
<a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/text.html" rel="noreferrer" target="_blank">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/text.html</a><br>
<br>
b. Alternatively we might consider specifying new HtmlTexture and SvgTexture nodes to simplify such layouts. Further integration of X3D into web pages is a very important area of work.<br>
<br>
c. Worth a deep look is efforts by Nicholas Polys on Display Techniques in Information-Rich Virtual Environments (IRVEs),<br>
<a href="http://scholar.lib.vt.edu/theses/available/etd-06152006-024611/unrestricted/DisplayTechniquesinIRVEs_final.pdf" rel="noreferrer" target="_blank">http://scholar.lib.vt.edu/theses/available/etd-06152006-024611/unrestricted/DisplayTechniquesinIRVEs_final.pdf</a><br>
and subsequent research papers which evaluate effectiveness of various text display strategies.<br>
<br>
d. There are a few practical examples for Text/FontStyle in Chapter 3 of X3D for Web Authors:<br>
<br>
<a href="http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter02-GeometryPrimitives" rel="noreferrer" target="_blank">http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter02-GeometryPrimitives</a><br>
<a href="http://x3dgraphics.com/slidesets/X3dForWebAuthors/Chapter02-GeometryPrimitives.pdf" rel="noreferrer" target="_blank">http://x3dgraphics.com/slidesets/X3dForWebAuthors/Chapter02-GeometryPrimitives.pdf</a><br>
<br>
e. Specified but not yet widely used: X3D ScreenFontStyle node.<br>
<a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/layout.html#ScreenFontStyle" rel="noreferrer" target="_blank">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/layout.html#ScreenFontStyle</a><br>
<br>
f. Somewhat speculative but most examples are pretty simple: 3D extruded text. Based on what's been done to date, am thinking that if we keep 2D text layouts then occasional alternatives using 3D fonts are workable as well.<br>
<br>
hmmmm....<br>
<br>
<br>
On 9/11/2015 6:02 AM, Andreas Plesch wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This is getting a bit off topic but there is related question I would like get feedback on. Currently, perhaps for some historic reason, x3dom centers all text at the local origin by default, like justify='"MIDDLE" "MIDDLE"' for single line text. It does that also for left aligned multi-line text, eg. it centers the bounding box of the complete text box at the origin.<br>
<br>
I believe that kind of alignment cannot be represented with a justify value although it seems actually what may be expected not unreasonably by some as a default positioning. '"MIDDLE" "MIDDLE"' for multi-line text would center the box at the origin but at the same time also center all lines for a middle alignment. Currently this positioning can only be achieved by using a transform around the text and routing x-offsets into it. Even some scripting is required for the simple math involved.<br>
<br>
What this means is that perhaps a third value for the MFString justify field would be needed,dealing with 'absolute' positioning of the major (x) axis, similar to minor alignment. There may be a way to make this backwards compatible as well.<br>
<br>
Andreas<br>
<br>
<br>
<br></blockquote></blockquote></div></div></div></div></div></div></blockquote></div><br clear="all"><br>-- <br><div class="gmail_signature">Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453</div>
</div></div></div>