862995 - length calculation for SVG text on a path failure

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[johann]

Attachment: text-on-a-path: text-length failure and path artifacts

User Agent: Mozilla/5.0 (Windows NT 6.0; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17.1
Build ID: 20130410205058

Steps to reproduce:

applied text to path using:
offset method
offset/text-anchor method



Actual results:

both usages displayed failure to correctly measure the length of text from std sys fonts


Expected results:

offsets and anchoring should have been accurate

Comment 1

[Robert Longson [:longsonr]]

Can you explain what's wrong please? Apart from the fleur-dy-lis symbol which displays as dots on my system and for which you've raised a separate bug, this looks pretty much the same in Opera to me.

Comment 2

[johann]

1.) there is no fleur-dy-lis symbol in the text;
2.) the text uses the std sys 'palatino linotype' family (pala.ttf);
3.) all of the text is upper case from the 'greek' page (1253: 0x0391 - 0x03a9); and
4.) this text is a biblical citation (minus the era's diacritics) and is part of a much larger XML+SVG image.

although straying from the gecko nature of this bug, yes, i also find that opera calcs the length properly. however, when i use opera(12.02 Build 1578), i find that the font family is ignored entirely and some other font is served instead of the called installed/sys font. you must be experiencing some sort of similar font-usage problem. i did not file a bug with opera since they will catch up with the crowd in the webkit conversion process.

are you pulling the file from the example file or the URL? i do not know if this can make a difference in opera.

the other, "artifact" bug (https://bugzilla.mozilla.org/show_bug.cgi?id=862997) is also strictly a gecko engine problem: no other engine shows that problem.

now, back to this gecko bug: the text-length mis-calculation. if you will notice the text length needed in 'textpath' is wrong and this makes the use of anchors/offsets to mis-align in gecko compared to other engines which get the right length.

this problem is this gecko-only bug.

Comment 3

[Robert Longson [:longsonr]]

  is what I'm calling a fleur-de-lis, it looks like that to me.

The position of the remaining characters seems to be very similar to Opera.

Comment 4

[johann]

AH!

that is the same as a '&nnbsp;' (a "narrow" non-breaking space). i really should take that out and replace it with whatever since it is not recognized as a separately "widthed" glyph by anybody when doing SVG.

i am not sure what you are seeing. to those of us that have tried, the 'text-anchor="middle"' and 'startOffset="50%"' causes the text to start a few pixels from the starting point of the path (the small white cross is perfectly centered across the path's starting point) and ends many more pixels than that from the ending point (i.e., gecko does not know how long the text really is). other engines get this right!

if i set the anchor at more than 50% to get gecko to properly center the text, all the other engines do the right thing and the text is shifted too far past the center to be, um, "centered".

Comment 5

[Robert Longson [:longsonr]]

So we're talking a few pixels different. You just need to delete all the whitespace and comments before and after the text to make it come out the way you want.

Comment 6

[Robert Longson [:longsonr]]

Fortunately this is fixed on trunk if svg.text.css-frames.enabled is set to true.

Comment 7

[Robert Longson [:longsonr]]

(In reply to johann from comment #4)
> AH!
> 
> that is the same as a '&nnbsp;' (a "narrow" non-breaking space). i really
> should take that out and replace it with whatever since it is not recognized
> as a separately "widthed" glyph by anybody when doing SVG.
> 

That too is fixed on trunk once svg.text.css-frames.enabled is set to true.

Comment 8

[Robert Longson [:longsonr]]

So if you want to see what I mean download this: http://nightly.mozilla.org/ then type about:config in the address bar and press return. Set svg.text.css-frames.enabled to true and then display your testcase and voila it all works. We're working on fixing the remaining bugs preventing us from turning svg.text.css-frames.enabled to true (bug 839955 is tracking that).

Comment 9

[johann]

i was answering while you sent the last comment. i will go to the nightly and give it a whirl. meanwhile, my comment re versions <= 20.0.1 ...

i had let the comments remain to show the various ways i tried to make it work. all of them resulted in the same mis-display in gecko.

however, you are right that the comments somehow interfere with gecko's capability to calc the length. after removing the comments gecko then comes close, IE remains more true, and webkit is still spot on.

thank you very much for this suggestion. i hope that this over a lot of the past versions. somehow, i have not run into this problem before.

i have tried svg.text.css-frames.enabled:true with nnbsp and i still seem to get a width sub as it does not come out narrower. are there other 'svg.text' setting requirements? this is strictly for my info as i cannot, obviously, play to those settings for the image itself.

since i cannot use word-spacing, i will have to remove one of the inter-word glyphs because gecko differently re-renders at different zooms (the text ends up starting at different places and sometimes over-writes the mid-point cross).

this increases the start-end gap, but at least it is cross-browser "workable".

the word-spacing i would like is: http://2secure.us/pub/cra/artifacts_top.svg

and what i will have to settle for is: http://2secure.us/pub/cra/artifacts_top_2.svg

this is quite acceptable, but you will notice that the eta has still has a very small offset from the mid-point compared to the sigma.

once again, thank you for your time getting to an acceptable solution.

Comment 10

[Robert Longson [:longsonr]]

Did you set svg.text.css-frames.enabled on the nightly or on 20.0.1? svg.text.css-frames.enabled does nothing on 20.0.1

Comment 11

[johann]

sorry, i should have been specific: i tried the setting on 20.0 first to get the result i reported.

Comment 12

[johann]

Robert:

more-or-less as a personal aside i would like to pass on a tidbit. just to cover the bases, i increased the font stack to: font-family="'Palatino Linotype', 'Palatino', 'Book Antiqua', serif" from font-family="'Palatino Linotype'". this range covers macs even before OSX and windows NT/98 with valid families and defaults the rest.

when i came to opera, i was surprised that it now pulled the right font (the first in the list)! i know this because i do not have 'Palatino'. moreover, looking at the upsilon we see the classical glyph of the original Zpaf and neither the modern glyph of 'Book Antigua' nor the generic "Y" from the default 'serif'. interesting, no!?