Open Bug 308338 Opened 19 years ago Updated 2 years ago

Support the 'baseline-shift' property in SVG

Categories

(Core :: SVG, enhancement)

Product:
Core
Component:
SVG
Type:
enhancement

Tracking

()

People

(Reporter: doug, Unassigned)

References

(
URL
)

Details

(4 keywords)

Attachments

(4 files, 1 obsolete file)

baseline shift not working
767 bytes, image/svg+xml
Details
style system only
16.57 KB, patch
dbaron
: review-
Details | Diff | Splinter Review
address review comment
10.94 KB, patch
roc
: review+
Details | Diff | Splinter Review
Example SVG containing graphics and super/sub scripts
14.00 KB, image/svg+xml
Details 
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.

    
    

    
  
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>


    
    

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

    
    

    
  
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.

    
    

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

    
    

    
  
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: parity-opera
Assignee: general → nobody
QA Contact: ian → general

    
    

    
  
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
Summary: baseline-shift does not seem to work → Support the 'baseline-shift' property in SVG
Assignee: nobody → longsonr

    
    

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

passes style system mochitests

        Attachment #439947 -
        Attachment description: style system only so far → style system only

        Attachment #439947 -
        Flags: review?(dbaron)

    
    

    
  

      
      
      
      

        Attached patch
          
          
        the SVG bit (obsolete)
        — 
          — Splinter Review
      

    


  

        Attachment #441915 -
        Flags: review?(roc)

    
    

    
  
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!

    
    

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

        Attachment #441915 -
        Attachment is obsolete: true

        Attachment #441915 -
        Flags: review?(roc)

    
    

    
  


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

        Attachment #441971 -
        Flags: review?(roc)

    
    

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

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

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

    
    

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

    
    

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

    
    

    
  
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.

    
    

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

    
    

    
  
I think baseline-shift should just be ignored in line layout when alignment-baseline is top or bottom.
Assignee: longsonr → nobody

    
    

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

    
    

    
  
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.

    
    

    
  
(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!

    
    

    
  
This bug clearly depend of bug 655877 ;)
Depends on: svgtext

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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

    
    

    
  
(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!

    
    

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

    
    

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

    
    

    
  
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.

    
    

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

    
    

    
  
(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

    
    

    
  
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.

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
Cameron, what are your thoughts now that bug 839955 is fixed?
Flags: needinfo?(cam)

    
    

    
  
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.
Flags: needinfo?(cam)

    
    

    
  
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.

    
    

    
  
David, do you know how far away an updated draft of a spec that defines these baseline properties is?
Flags: needinfo?(dbaron)

    
    

    
  
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.
Flags: needinfo?(dbaron)

    
    

    
      
  

    
    

    
  
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!

    
    

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

    
    

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

    
    

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

    
    

    
  
(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

    
    

    
      
  

    
    

    
      
  
Severity: normal → enhancement
OS: Windows XP → All
Hardware: x86 → All
Whiteboard: parity-opera → [parity-chrome][parity-opera]

    
    

    
  
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>

    
    

    
  
(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.
Whiteboard: [parity-chrome][parity-opera] → [parity-chrome][parity-safari][parity-presto opera]

    
    

    
  
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome, 
          
            parity-opera-mini, 
          
            parity-safari
Whiteboard: [parity-chrome][parity-safari][parity-presto opera]

    
  
Severity: normal → S3

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: