[x3d-public] text minor alignment - additional enumeration value? designing better test layout?

[Andreas Plesch]

I updated the test scene at

http://andreasplesch.github.io/x3dom/x3dom_text/driver_x3dom.xhtml

with an additional button at the bottom center which toggles between BEGIN,
MIDDLE, and END major positioning of the text as envisioned.

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).



On Tue, Oct 6, 2015 at 5:50 PM, Andreas Plesch <andreasplesch at gmail.com>
wrote:

> Don, let me update
>
> http://andreasplesch.github.io/x3dom/x3dom_text/driver_x3dom.xhtml
>
> 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.
>
> 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.
> So "BEGIN BEGIN" implies BEGIN, but "END BEGIN" implies END absolute major
> positioning.
> 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:
>
>
> left aligned line 1   |
> line 2 is here        |
> line 3 could be longer|
>                       x=0
>
> "BEGIN BEGIN MIDDLE" would center left aligned text at the Y axis.
>
> left align|ed line 1
> line 2 is |here
> line 3 at |the end
>           x=0
>
> I am pretty sure this idea can be mapped to right to left or/and vertical
> text as well.
> Although it sounds complicated I think a third alignment argument for
> absolute major (horizontal) positioning of the text box would be quite
> useful.
>
> 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.
>
> 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).
>
> PdfTexture may be another option which would have the advantage of good
> reproducibility.
>
> 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 (
> https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics) but they
> are not well supported.
>
> 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 ?
> 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.
>
> some ideas,
>
> Andreas
>
>
>
> On Tue, Oct 6, 2015 at 9:50 AM, Don Brutzman <brutzman at nps.edu> wrote:
>
>> Thanks for the careful thinking Andreas.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> All this probably deserves further investigation:
>>
>> 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.
>>
>>
>> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/text.html
>>
>> 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.
>>
>> c. Worth a deep look is efforts by Nicholas Polys on Display Techniques
>> in Information-Rich Virtual Environments (IRVEs),
>>
>> http://scholar.lib.vt.edu/theses/available/etd-06152006-024611/unrestricted/DisplayTechniquesinIRVEs_final.pdf
>> and subsequent research papers which evaluate effectiveness of various
>> text display strategies.
>>
>> d. There are a few practical examples for Text/FontStyle in Chapter 3 of
>> X3D for Web Authors:
>>
>>
>> http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter02-GeometryPrimitives
>>
>> http://x3dgraphics.com/slidesets/X3dForWebAuthors/Chapter02-GeometryPrimitives.pdf
>>
>> e. Specified but not yet widely used: X3D ScreenFontStyle node.
>>
>> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/layout.html#ScreenFontStyle
>>
>> 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.
>>
>> hmmmm....
>>
>>
>> On 9/11/2015 6:02 AM, Andreas Plesch wrote:
>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> Andreas
>>>
>>>
>>>
>>>

-- 
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20151007/6b2d0ba0/attachment.html>