308338 - Support the 'baseline-shift' property in SVG

Status: NEW

(Core :: SVG, enhancement)

Description

[Doug Schepers]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

'baseline-shift' lets you do numerous things, among them, center text
vertically. None of the values for 'baseline-shift' seem to work, including the
keywords '      baseline', 'sub', 'super', nor numeric values such as
percentages (-33%) or pixel/point units.

Reproducible: Always

Steps to Reproduce:
1. View the text file: http://svg-whiz.com/svg/mozilla/baseline-shift.svg
2. Try setting any value in your own test case.
3. Observe the results when compared with those in ASV.

Actual Results:  
'baseline-shift' had no effect on the vertical position of the text.

Expected Results:  
For each value listed above, 'baseline-shift' should have appropriately affected
the vertical position of the text.

This is commonly used to position text so it is centered inside 'rect' elements,
to serve as a button.

Comment 1

[Doug Schepers]

Attachment: baseline shift not working

Comment 2

[Antoine Buat]

JavaScript Console reports:

Error: Unknown property ''.  Declaration dropped.

or when used in a CSS:

Error: Unknown property 'baseline-shift'.  Declaration dropped.

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet href="test_libobject.css" type="text/css"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN"    
  "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
<svg xmlns="http://www.w3.org/2000/svg">
 <defs>
    <style type="text/css"><![CDATA[
      .tup3 {
      baseline-shift: 3;
      }
      .tdown3 {
      baseline-shift: -3;
      }
    ]]></style>
  </defs>
  <line x1="0" x2="200" y1="50" y2="50"/>
  <text x="0" y="50">normal</text>
  <text x="50" y="50" class="tup3">up3</text>
  <text x="100" y="50" class="tdown3">down3</text>
</svg>

Comment 3

[zug_treno]

*** Bug 319767 has been marked as a duplicate of this bug. ***

Comment 4

[Matt]

Just to mention, I have yet to find an SVG renderer that displays that correctly.  Ksvg was closest as it at least used baseline-shift properly, but it subsequently farked up other things.

Comment 5

[David Strozzi]

Hi,

I noticed superscripts via baseline-shift still doesn't work in BonEcho alpha3 on linux.  I have a simple test-case showing this, but it seems folks have already submitted some.  As has been said, other viewers foul this up too, such as display from the much-revered ImageMagick...

Comment 6

[Steve Chapel]

Confirming in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060804 Minefield/3.0a1. Opera 9.01 renders the same SVG with the specified baseline-shift.

Comment 11

[Jonathan Watt [:jwatt]]

As well as the ltr test in the URL field, this bug also prevents us correctly rendering:

http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-text-align-06-b.html

Comment 13

[Robert Longson [:longsonr]]

Attachment: style system only

Comment 14

[Robert Longson [:longsonr]]

Comment on attachment 439947 [details] [diff] [review]
style system only

passes style system mochitests

Comment 15

[Robert Longson [:longsonr]]

Attachment: the SVG bit

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Seems to me you should check the element type to ensure we only apply baseline-shift on 'tspan', 'tref', 'altGlyph', 'textPath' elements. Should have tests for that.

Otherwise looks great!

Comment 17

[Robert Longson [:longsonr]]

Which basically means everything but 'text' atm. Will adjust GetBaselineShift appropriately.

Comment 18

[Robert Longson [:longsonr]]

Attachment: address review comment

Fixed not to do <text> with reftest adjusted to check.

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Is there a good reason the SVG spec created a new property rather than using 'vertical-align'?

Comment 20

[Robert Longson [:longsonr]]

I've asked the SVG WG: http://lists.w3.org/Archives/Public/www-svg/2010Apr/0138.html

Comment 21

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

A little more history here, some of which I'd forgotten:

'vertical-align' was in CSS1 and CSS2:
http://www.w3.org/TR/REC-CSS1-961217#vertical-align
http://www.w3.org/TR/1998/REC-CSS2-19980512/visudet.html#propdef-vertical-align

XSL-FO turned 'vertical-align' into a shorthand for 4 properties (alignment-baseline, alignment-adjust, baseline-shift, dominant-baseline):
http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#vertical-align

SVG 1.0 adopted three of those four properties (alignment-baseline and baseline-shift, and dominant-baseline):
http://www.w3.org/TR/2001/REC-SVG-20010904/text.html

(I think XSL-FO went first here, partly based on the thread above, but I'm not sure.  I didn't dig into the chain of working drafts.)

css3-linebox proposes applying the split that XSL-FO does to CSS as well:
http://www.w3.org/TR/2002/WD-css3-linebox-20020515/#baseline



So implementing 'baseline-shift' as a property separate from 'vertical-align' rather than as a subproperty of a 'vertical-align' shorthand is incompatible with the css3-linebox proposal to align CSS with the XSL-FO feature additions.

Comment 22

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

And to be clear here:  the really big incompatibility here is that XSL-FO and the draft css3-linebox make baseline-shift a subproperty of a vertical-align shorthand whereas SVG makes it unrelated to vertical-align.

Comment 23

[Robert Longson [:longsonr]]

So I should reimplement baseline-shift so it works like margin-top (where vertical-align is the equivalent to margin) say but with the difference that the number of values will be the same in both cases.

In other words baseline-shift just parses into a vertical-align CSS object and I then use that in SVG as baseline-shift.

Comment 24

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I don't think so.

I think what we should do, ideally, is change vertical-align into a shorthand:  i.e., remove the mVerticalAlign from the various structs, move mDominantBaseline into nsStyleTextReset, and add mBaselineShift and mAlignmentBaseline there, and then change the code that uses vertical-align in line layout and tables to use the appropriate subproperties.  The main tricky thing about this (ignoring the details of this split) is adding appropriate serialization code for 'vertical-align' in nsCSSDeclaration::GetValue.

However, there are a few things that are tricky about this split in particular:
 * XSL-FO specifies that <length> and <percentage> on 'vertical-align' got to alignment-adjust rather than baseline-shift.  I'm not sure yet if this matters, or would require us to add the fourth property.
 * I think there are some tricky line layout implications, but I need to look more closely.


It also seems from bug 527376 that some SVG implementations may support 'vertical-align', so this would be good in that it would make vertical-align and baseline-shift both work.

But I'm not sure if this is worth the work, either.

Comment 25

[Robert Longson [:longsonr]]

Are there any existing CSS properties implemented in gecko that work this way?

Comment 26

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Every shorthand property works that way; I'm just describing in slightly more detail how you'd turn it into a shorthand.

Comment 27

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It might be worth seeing where the discussion in www-svg goes before deciding what approach we should take.

Comment 28

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So that discussion sort of petered out.

I think if we want this we should do the following:
 * implement alignment-baseline, baseline-shift, and dominant-baseline as
   subproperties of the 'vertical-align' shorthand in the style system:
   + all values of 'vertical-align' set 'dominant-baseline' to 'auto'
   + sub, super, <percentage> and <length> values of vertical-align set
     baseline-shift to the value given and alignment-baseline to baseline
   + other values of vertical-align set baseline-shift to baseline and
     alignment-baseline to the value given
 * change the line layout code that looks at mVerticalAlign to look at
   mAlignmentBaseline and mBaselineShift (this introduces some new features)
 * change the table code that looks at mVerticalAlign to look at
   mAlignmentBaseline
 * don't worry about fixing our dominant-baseline implementation (which looks
   pretty sketchy/broken right now, in addition to being SVG-only)

See comment 24 for slightly more details on the style system changes, although I'd probably need to write more.

However, I think the line layout changes might be nontrivial -- I'm not sure I understand the interaction between baseline-shift and alignment-baseline: top/bottom.  Probably the best source for that would be the XSL spec, but I haven't yet dug up the relevant part.  If the interaction is anything other than "baseline-shift is ignored when alignment-baseline is top or bottom", then the line layout changes are potentially hard.

Comment 29

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #28)
> However, I think the line layout changes might be nontrivial -- I'm not sure I
> understand the interaction between baseline-shift and alignment-baseline:
> top/bottom.  Probably the best source for that would be the XSL spec, but I
> haven't yet dug up the relevant part.  If the interaction is anything other
> than "baseline-shift is ignored when alignment-baseline is top or bottom", then
> the line layout changes are potentially hard.

Actually, there's no useful source for this.  The SVG and XSL-FO specs both pretend that 'top' and 'bottom' do something entirely different from what they actually do.

Comment 30

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I think baseline-shift should just be ignored in line layout when alignment-baseline is top or bottom.

Comment 31

[fantasai]

I don't think vertical-align should reset dominant-baseline. (I also think splitting out vertical-align is overkill, but I can't really argue with the SVG spec...)

Comment 32

[David Mathog]

As a browser user I really don't care how this is fixed, only that it is.  This discussion has been going on for 7 years - is implementing baseline-shift really that difficult???

Pages like this:

  http://www.svgbasics.com/font_effects_italic.html

still do not render correctly with the latest firefox (11.0).  Neither super nor subscripts are working - both are drawn normal sized on the baseline.

Comment 33

[Paul A. Bristow]

(In reply to David Mathog from comment #32)
> As a browser user I really don't care how this is fixed, only that it is. 
> This discussion has been going on for 7 years - is implementing
> baseline-shift really that difficult???
> 
> Pages like this:
> 
>   http://www.svgbasics.com/font_effects_italic.html
> 
> still do not render correctly with the latest firefox (11.0).  Neither super
> nor subscripts are working - both are drawn normal sized on the baseline.

I agree - showing subscript and superscript is really important for showing math equations, units and chemical formulae.

PLEASE can someone at least make these render right!

Comment 34

[Jeremie Patonnier :Jeremie]

This bug clearly depend of bug 655877 ;)

Comment 35

[Cameron McCormack (:heycam)]

What is implementation status like in other browsers?  The SVG WG resolved to use vertical-align as the way to vertically shift text in SVG2.  If implementations are still spotty wrt baseline-shift, we might be able to drop it from the spec altogether.

Comment 36

[David Mathog]

Opera 11.62 supports super/sub in SVG.
IE 8 has no SVG support at all.  Later versions at least know about it:

  http://msdn.microsoft.com/en-us/library/ie/ff972254(v=vs.85).aspx

but I don't have a machine with IE 9 or higher to test that.

No info on chrome
No info on Safari

This is, I think, the standard test SVG for this property from w3:

http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlSVGWeb/text-align-02-b.html 

Opera deals with the entire set of text-align tests quite well, other than the last one (8) which is in any case marked "draft".  

Firefox has problems (most of them severe) with tests 2,4,5,6 and does the same thing as Opera on test 8.

Comment 37

[Paul A. Bristow]

IE 9 does text-align-02-b.svg right for the png image but the svg is blank.

Chrom does both svg and png pane right.

Firefox 11 makes no attempt to shift up or down - show text inline.

HTH

Comment 38

[chemwizard]

(In reply to Paul A. Bristow from comment #33)
> (In reply to David Mathog from comment #32)
> > As a browser user I really don't care how this is fixed, only that it is. 
> > This discussion has been going on for 7 years - is implementing
> > baseline-shift really that difficult???
> > 
> > Pages like this:
> > 
> >   http://www.svgbasics.com/font_effects_italic.html
> > 
> > still do not render correctly with the latest firefox (11.0).  Neither super
> > nor subscripts are working - both are drawn normal sized on the baseline.
> 
> I agree - showing subscript and superscript is really important for showing
> math equations, units and chemical formulae.
> 
> PLEASE can someone at least make these render right!

Since at least Opera 11.62 and Chrome 18.0.1025.142 m are both doing it right, I think it can't be that difficult! I can't believe that 7 years was not enough to get this bug fixed. But I sincerely hope that now there's going to be a bit of movement on this issue. Being an old Mozilla/Firefox user I would hate having to tell chemistry students to use the "much better Chrome" instead of FF!

Comment 39

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Paul A. Bristow from comment #33)
> I agree - showing subscript and superscript is really important for showing
> math equations, units and chemical formulae.

We support MathML, whose support for laying out math equations and chemical formulae blows away anything SVG can do. While I agree that some support for SVG baseline-shift is worth adding to Firefox, you should focus your energies on getting those other browsers to support MathML :-).

Comment 40

[Paul A. Bristow]

MathML is indeed wonderful, and should be supported, but MathML is overkill for the much, much more common need to write chemical formulae like H2O and units like m3.  It is really absurd that we can't easily do that.

(I have used Unicode U2070 superscripts and subscripts (see http://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts) to work around this, but not always possible).

Comment 41

[Will Pittenger]

I agree.  I don't need chemical formulas.  But when I do find a need for superscripts or subscripts, I'm wanting to put them into my SVG, not a browser. :P  Stupid idea to rely on a browser for a fix.

Comment 42

[Will Pittenger]

:p  I was thinking this was Inkscape, which has support for superscript and subscript.  Shows you what happens when you don't hear about a bug for a while.

Comment 43

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Paul A. Bristow from comment #40)
> MathML is indeed wonderful, and should be supported, but MathML is overkill
> for the much, much more common need to write chemical formulae like H2O and
> units like m3.  It is really absurd that we can't easily do that.

data:text/html,m<sup>3</sup> H<sub>2</sub>O

Comment 44

[Paul A. Bristow]

Doesn't work for me :-(

Inkscape supports sub and super using

   style="font-size:20px;baseline-shift:super"
   style="font-size:20px;baseline-shift:sub"

and this works badly on Chrome, not sub or super on Firefox, not on IE9,
and fine on Opera.

So this still needs fixing please.

Comment 45

[David Mathog]

(In reply to Paul A. Bristow from comment #44)
> Inkscape supports sub and super using
> 
>    style="font-size:20px;baseline-shift:super"
>    style="font-size:20px;baseline-shift:sub"
> 
> and this works badly on Chrome, not sub or super on Firefox, not on IE9,
> and fine on Opera.
> 
> So this still needs fixing please.

Exactly.  Also MathML is not a solution because the problem arises in SVG drawings which are, for instance, slides for a class, and include a mixture of graphics and text.  I will upload "page45.svg", which is a small example with minimal graphics but does give some idea of what the application is.  View it in Opera and it looks fine, in Firefox it looks terrible.

Comment 46

[David Mathog]

Attachment: Example SVG containing graphics and super/sub scripts

Comment 47

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to David Mathog from comment #45)
> Also MathML is not a solution because the problem arises in SVG
> drawings which are, for instance, slides for a class, and include a mixture
> of graphics and text.

That would work fine with MathML in a <foreignObject>.

But anyway, we're spamming this bug with useless information since everyone agrees we should implement baseline-shift in some way.

Comment 48

[Will Pittenger]

I'm not aware of Inkscape supporting the <foreignObject> element.  You could add it with the XML editor, but otherwise...

Comment 49

[PRO]

Here is another vivid existing example: http://commons.wikimedia.org/wiki/File:NucleicAcid.svg

Comment 50

[Jonathan Watt [:jwatt]]

Cameron, what are your thoughts now that bug 839955 is fixed?

Comment 51

[Cameron McCormack (:heycam)]

I feel like we should wait until http://dev.w3.org/csswg/css-inline-3/ becomes more stable, and then implement the set of baseline properties for block elements in general, which would make it work automatically for SVG.  Since the set of baseline properties in SVG <= 1.1 is different from those in css-inline-3, I wouldn't want to entrench the differences any further, given we'll be wanting to adopt the new ones in SVG.  I am not sure what the timeline is for css-inline-3, though.

It's possible we could hack baseline-shift so that it maps to vertical-align internally, just like we do for dominant-baseline currently.  But I haven't looked in to whether treating say baseline-shift:4px like vertical-align:4px is correct.

Comment 52

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Discussed in the CSS meeting 2014-05-20 (beginning of the afternoon).  Seem to be tending towards the idea that alignment-baseline and baseline-shift should be longhands of a shorthand vertical-align, but dominant-baseline should not.

Comment 53

[Cameron McCormack (:heycam)]

David, do you know how far away an updated draft of a spec that defines these baseline properties is?

Comment 54

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm not sure.

The discussion in question was http://krijnhoetmer.nl/irc-logs/css/20140520#l-1013

Reading that -- it looks like the plan *might* have been that the spec in question would (temporarily, at least) be SVG2.

Comment 55

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

https://drafts.csswg.org/css-inline/#line-height is working on defining the new split.

Comment 56

[xyzdragon]

(In reply to David Mathog from comment #32)
> As a browser user I really don't care how this is fixed, only that it is. 
> This discussion has been going on for 7 years - is implementing

I strongly support this statement from 2012. Now it's almost 11 years. This is one of the most basic SVG features.

Comment 57

[Paul A. Bristow]

Absolutely - I have given up development of an application to output SVG graph plots because Firefox can't even show m^2 as an axis label or H2O as a label.  PLEASE implement something!

Comment 58

[xyzdragon]

(In reply to Paul A. Bristow from comment #57)
> Absolutely - I have given up development of an application to output SVG
> graph plots because Firefox can't even show m^2 as an axis label or H2O as a
> label.  PLEASE implement something!

Actually that's the same reason I wrote here. I wanted to doe an SVG animation with many subscripts. But neither does Firefox support it, nor does the svgrender addon work anymore and I don't know of any other methods of converting SVG to a gif, which is another problem. Despite it's age I find SVG poorly supported because of this. I used C++ and SDL now which was a major waste of time.

Comment 59

[Will Pittenger]

(In reply to Paul A. Bristow from comment #57)
> Absolutely - I have given up development of an application to output SVG
> graph plots because Firefox can't even show m^2 as an axis label or H2O as a
> label.  PLEASE implement something!

The workaround is to use kerning.

Comment 60

[David Mathog]

Re: comment 58, use Inkscape to convert SVG to PNG.  To get from PNG to gif use some other tool.

Comment 61

[Will Pittenger]

(In reply to David Mathog from comment #60)
> Re: comment 58, use Inkscape to convert SVG to PNG.  To get from PNG to gif
> use some other tool.

And why do you create your images in SVG to start with?  SVGs can be scaled.  PNG and GIF can't.  Plus, if you convert the result to GIF, you're limited to 256 colors. :p

Comment 62

[xyzdragon]

(In reply to Will Pittenger from comment #61)
> (In reply to David Mathog from comment #60)
> > Re: comment 58, use Inkscape to convert SVG to PNG.  To get from PNG to gif
> > use some other tool.
> 
> And why do you create your images in SVG to start with?  SVGs can be scaled.
> PNG and GIF can't.  Plus, if you convert the result to GIF, you're limited
> to 256 colors. :p

I want to use >animated< SVGs (with baseline-shift). As far as I know Inkscape can't handle those.

That is also why I want to use SVGs. I would grow old trying to draw every frame manually in Gimp, instead I want to use the built in animation features of SVG. Also I like to have a scalable picture lying around, furthermore, I could use C++ to automatically generate a longer animated SVG. I actually created animated SVGs several MB large, which helped me to visualize some internal programming data structure automatically and way easier and more pretty than SDL(or anything comparable), also I don't want to use SDL in some applications, just to output an animation of what is happening, e.g. because I don't even have an X-Server. Those very large SVGs are a bit laggy though and that is why I want to render them to trivially displayable GIF animations. In short, I love SVG, but I lament that it is not supported well/to the full extent in any program.

In any case, this is getting off topic, I'm sorry, I just wanted to bump this thread and incite development, because I don't have the abilities to contribute. So it is not a matter for what I need it, but how and when to implement it.

Comment 63

[David Mathog]

This is off topic for xyzdragon.  See if anything here:

  https://inkscape.org/en/learn/animation/

helps.

Comment 64

[bugzilla]

I didn't quite get Will Pittengers proposal to use kerning as a workaround. Best solution I could come up with was to use dy. For example:

<text>This is <tspan dy="5px">super</tspan></text>

Comment 65

[Will Pittenger]

(In reply to bugzilla from comment #64)
> I didn't quite get Will Pittengers proposal to use kerning as a workaround.
> Best solution I could come up with was to use dy. For example:
> 
> <text>This is <tspan dy="5px">super</tspan></text>

Actually, that could be how Inkscape does kerning.  I haven't checked the XML Editor for a while with superscript/subscript elements.

Comment 66

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)