[x3d-public] text minor alignment - additional enumeration value? designing better test layout?
Andreas Plesch
andreasplesch at gmail.com
Tue Oct 6 14:50:41 PDT 2015
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
>>
>>
>>
>>
>> On Fri, Sep 11, 2015 at 8:26 AM, Andreas Plesch <andreasplesch at gmail.com
>> <mailto:andreasplesch at gmail.com>> wrote:
>>
>> Hello,
>>
>> as I looked into the 'length' and 'maxExtent' fields of the text
>> node, I noticed similar issues with snapshots for the NIST conformance
>> example scenes. For those fields it turns out that they are not widely
>> supported in players, sofar only BS Contact seems to have support while
>> freeWrl, view3dscene and InstantPlayer do not.
>>
>> I think both 'length' and 'maxExtent' could be implemented for x3dom
>> due to the way it renders text. 'length' is very similar to the maxWidth
>> parameter of ctx.fillText() for canvas, and maxExtent is defining a texture
>> mapping.
>>
>> Andreas
>>
>>
>> On Wed, Sep 9, 2015 at 5:07 PM, Roy Walmsley <
>> roy.walmsley at ntlworld.com <mailto:roy.walmsley at ntlworld.com>> wrote:
>>
>> Andreas,____
>>
>> __ __
>>
>> Thanks for the update. Perhaps all it needs is for the snapshot
>> to be regenerated, and also the first slide in the show.____
>>
>> __ __
>>
>> Roy____
>>
>> __ __
>>
>> *From:*Andreas Plesch [mailto:andreasplesch at gmail.com <mailto:
>> andreasplesch at gmail.com>]
>> *Sent:* 09 September 2015 21:43
>> *To:* Roy Walmsley
>> *Cc:* X3D Graphics public mailing list
>> *Subject:* Re: [x3d-public] text minor alignment____
>>
>> __ __
>>
>> Hello Roy,____
>>
>> thanks for reviewing this issue. In the mean time I had
>> opportunity to view the scene with freeWrl and InstantPlayer. Both render
>> the scene as expected, eg. with the first line above the x-axis while its
>> baseline just touches it. So I think something was a bit off when the
>> snapshot on the archive web site was generated.____
>>
>> Andreas____
>>
>> __ __
>>
>> __ __
>>
>> On Wed, Sep 9, 2015 at 8:14 AM, Roy Walmsley <
>> roy.walmsley at ntlworld.com <mailto:roy.walmsley at ntlworld.com>> wrote:____
>>
>> Andreas,____
>>
>> ____
>>
>> I have reviewed your comments below and find that I am in
>> agreement with you.____
>>
>> ____
>>
>> You are correct in saying that the default for the /justify/
>> field is [“BEGIN” “FIRST”]. This is quite clearly stated in 15.2.2.3 of the
>> 19775-1 specification.____
>>
>> ____
>>
>> Then, when /horizontal/ is TRUE and /topToBottom/ is TRUE, which
>> both are by default, Table 15.4 in the 19775-1 specification states that
>> when the minor alignment is “FIRST” the baseline of the first line shall be
>> aligned with the origin.____
>>
>> ____
>>
>> The inevitable conclusion is that the figure displaying the NIST
>> Conformance for the default field settings is incorrect. I will raise this
>> issue for discussion at the next available opportunity. Please keep us
>> informed of any further findings.____
>>
>> ____
>>
>> Great catch. Thank you.____
>>
>> ____
>>
>> Regards,____
>>
>> ____
>>
>> Roy
>>
>>
>> ____
>>
>> ____
>>
>> -- ____
>>
>> Andreas Plesch
>> 39 Barbara Rd.
>> Waltham, MA 02453____
>>
>>
>>
>>
>>
>> --
>> Andreas Plesch
>> 39 Barbara Rd.
>> Waltham, MA 02453
>>
>>
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>
>>
>
> all the best, Don
> --
> Don Brutzman Naval Postgraduate School, Code USW/Br
> brutzman at nps.edu
> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA
> +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics
> http://faculty.nps.edu/brutzman
>
--
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/20151006/32f11187/attachment-0001.html>
More information about the x3d-public
mailing list