Last Comment Bug 308338 - Support the 'baseline-shift' property in SVG
: Support the 'baseline-shift' property in SVG
Status: NEW
[parity-chrome][parity-opera]
: dev-doc-needed
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: All All
: -- enhancement with 24 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
http://www.w3.org/Graphics/SVG/Test/2...
: 319767 382669 385675 401102 494717 527376 (view as bug list)
Depends on: svgtext 839955
Blocks: svg11tests
  Show dependency treegraph
 
Reported: 2005-09-13 09:11 PDT by Doug Schepers
Modified: 2016-05-02 09:16 PDT (History)
36 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
baseline shift not working (767 bytes, image/svg+xml)
2005-09-27 21:50 PDT, Doug Schepers
no flags Details
style system only (16.57 KB, patch)
2010-04-19 09:33 PDT, Robert Longson
dbaron: review-
Details | Diff | Splinter Review
the SVG bit (10.74 KB, patch)
2010-04-27 13:41 PDT, Robert Longson
no flags Details | Diff | Splinter Review
address review comment (10.94 KB, patch)
2010-04-27 16:11 PDT, Robert Longson
roc: review+
Details | Diff | Splinter Review
Example SVG containing graphics and super/sub scripts (14.00 KB, image/svg+xml)
2012-08-09 08:40 PDT, David Mathog
no flags Details

Description Doug Schepers 2005-09-13 09:11:47 PDT
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 2005-09-27 21:50:48 PDT
Created attachment 197661 [details]
baseline shift not working
Comment 2 Antoine Buat 2005-11-15 15:53:06 PST
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 2005-12-11 02:26:53 PST
*** Bug 319767 has been marked as a duplicate of this bug. ***
Comment 4 Matt 2005-12-26 18:30:12 PST
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 2006-06-01 08:23:37 PDT
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 2006-08-08 11:17:08 PDT
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 7 Robert Longson 2007-06-01 00:35:17 PDT
*** Bug 382669 has been marked as a duplicate of this bug. ***
Comment 8 Robert Longson 2007-06-24 13:09:04 PDT
*** Bug 385675 has been marked as a duplicate of this bug. ***
Comment 9 Robert Longson 2007-10-25 09:35:37 PDT
*** Bug 401102 has been marked as a duplicate of this bug. ***
Comment 10 Robert Longson 2009-05-24 14:27:41 PDT
*** Bug 494717 has been marked as a duplicate of this bug. ***
Comment 11 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2009-08-25 16:00:23 PDT
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 12 Robert Longson 2009-11-09 01:53:21 PST
*** Bug 527376 has been marked as a duplicate of this bug. ***
Comment 13 Robert Longson 2010-04-19 09:33:20 PDT
Created attachment 439947 [details] [diff] [review]
style system only
Comment 14 Robert Longson 2010-04-27 13:38:39 PDT
Comment on attachment 439947 [details] [diff] [review]
style system only

passes style system mochitests
Comment 15 Robert Longson 2010-04-27 13:41:09 PDT
Created attachment 441915 [details] [diff] [review]
the SVG bit
Comment 16 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-04-27 14:25:36 PDT
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 2010-04-27 14:32:50 PDT
Which basically means everything but 'text' atm. Will adjust GetBaselineShift appropriately.
Comment 18 Robert Longson 2010-04-27 16:11:50 PDT
Created attachment 441971 [details] [diff] [review]
address review comment

Fixed not to do <text> with reftest adjusted to check.
Comment 19 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2010-04-27 19:17:16 PDT
Is there a good reason the SVG spec created a new property rather than using 'vertical-align'?
Comment 20 Robert Longson 2010-04-27 23:54:47 PDT
I've asked the SVG WG: http://lists.w3.org/Archives/Public/www-svg/2010Apr/0138.html
Comment 21 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2010-04-28 08:13:12 PDT
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-7 (busy September 14-25) 2010-04-28 08:14:21 PDT
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 2010-04-28 08:40:52 PDT
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-7 (busy September 14-25) 2010-04-28 08:52:21 PDT
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 2010-04-29 03:02:01 PDT
Are there any existing CSS properties implemented in gecko that work this way?
Comment 26 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2010-04-29 14:53:25 PDT
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-7 (busy September 14-25) 2010-04-29 14:54:14 PDT
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-7 (busy September 14-25) 2010-05-17 17:30:18 PDT
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-7 (busy September 14-25) 2010-05-17 17:32:38 PDT
(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-7 (busy September 14-25) 2010-05-17 23:34:19 PDT
I think baseline-shift should just be ignored in line layout when alignment-baseline is top or bottom.
Comment 31 fantasai 2012-02-13 08:19:50 PST
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 2012-03-28 12:09:20 PDT
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 2012-03-29 01:28:35 PDT
(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 2012-03-29 02:12:41 PDT
This bug clearly depend of bug 655877 ;)
Comment 35 Cameron McCormack (:heycam) (away Sep 28) 2012-03-29 03:45:31 PDT
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 2012-03-29 09:36:38 PDT
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 2012-03-29 10:00:15 PDT
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 2012-03-31 14:00:51 PDT
(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) 2012-08-08 19:41:48 PDT
(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 2012-08-09 02:14:05 PDT
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 2012-08-09 02:37:03 PDT
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 2012-08-09 02:39:31 PDT
: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) 2012-08-09 02:53:23 PDT
(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 2012-08-09 07:11:11 PDT
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 2012-08-09 08:39:42 PDT
(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 2012-08-09 08:40:38 PDT
Created attachment 650582 [details]
Example SVG containing graphics and super/sub scripts
Comment 47 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-08-09 17:09:31 PDT
(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 2012-08-09 17:24:14 PDT
I'm not aware of Inkscape supporting the <foreignObject> element.  You could add it with the XML editor, but otherwise...
Comment 49 PRO 2012-10-26 10:20:30 PDT
Here is another vivid existing example: http://commons.wikimedia.org/wiki/File:NucleicAcid.svg
Comment 50 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2013-11-04 04:37:23 PST
Cameron, what are your thoughts now that bug 839955 is fixed?
Comment 51 Cameron McCormack (:heycam) (away Sep 28) 2013-11-04 14:10:11 PST
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-7 (busy September 14-25) 2014-05-19 21:50:15 PDT
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) (away Sep 28) 2014-06-03 22:20:53 PDT
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-7 (busy September 14-25) 2014-06-03 23:38:43 PDT
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-7 (busy September 14-25) 2015-08-26 03:58:46 PDT
https://drafts.csswg.org/css-inline/#line-height is working on defining the new split.
Comment 56 xyzdragon 2015-11-17 05:32:46 PST Comment hidden (advocacy)
Comment 57 Paul A. Bristow 2015-11-17 06:21:56 PST
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 2015-11-17 06:31:01 PST
(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 2015-11-17 06:44:44 PST
(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 2015-11-17 09:26:10 PST
Re: comment 58, use Inkscape to convert SVG to PNG.  To get from PNG to gif use some other tool.
Comment 61 Will Pittenger 2015-11-17 09:32:39 PST
(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 2015-11-17 14:42:28 PST Comment hidden (off-topic)
Comment 63 David Mathog 2015-11-17 14:51:23 PST Comment hidden (off-topic)
Comment 64 bugzilla 2016-05-02 09:03:19 PDT
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 2016-05-02 09:16:31 PDT
(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.

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