Closed Bug 316564 Opened 14 years ago Closed 12 years ago

Inline SVG text will not display on Mac when after <h1> element. Testcase attached.

Categories

(Core :: SVG, defect)

1.8 Branch
PowerPC
macOS
defect
Not set

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: tow21, Unassigned)

References

Details

Attachments

(4 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051107 Firefox/1.5
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051107 Firefox/1.5

The offending page is xhtml with inline SVG. When the first thing in the body of the document is the inline SVG, it is displayed correctly.

If it is preceded in the body by an xhtml <h1> element (or any of the <h?> header elements), then the SVG is all displayed - with the exception of any text which will not be shown. If the <h1> element follows the SVG, there is no problem.

This does not occur under Linux, but does under Mac OS X (I don't know about Windows.)

Reproducible: Always

Steps to Reproduce:
1. Load document
2. Look.
3.

Actual Results:  
SVG displayed without text

Expected Results:  
SVG displayed with text.

The offending document will be attached: comment out the "<h1></h1>", or move it to after the SVG and the document will be displayed correctly.
Attached file Amended testcase
In fact, further investigation reveals that it is not necessarily an <h?> tag that is necessary to trigger the bug - it is an xhtml element whose style includes a non-zero margin.

An amended file is attached - if the margin is set to zero, the text in the SVG will appear; if the margin is greater than zero, then the text will not appear.
Component: General → SVG
Product: Firefox → Core
Version: unspecified → 1.8 Branch
Assignee: nobody → general
QA Contact: general → ian
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

yet another test case (involves some drag&drop javascript code) regarding svg-text not being displayed properly. the text is drawn correctly at first, but when dragging the parent div around it isn't (always) redrawn. console says:

Feb 27 01:41:14 G3 /Applications/Firefox.app/Contents/MacOS/firefox-bin: CGBitmapContextCreate: unsupported parameter combination: 2 integer bits/component; 8 bits/pixel; 3-component colorspace; kCGImageAlphaPremultipliedFirst.
Feb 27 01:41:14 G3 /Applications/Firefox.app/Contents/MacOS/firefox-bin: CGContextConcatCTM: invalid context
Feb 27 01:41:14 G3 /Applications/Firefox.app/Contents/MacOS/firefox-bin: CGContextConcatCTM: invalid context
Feb 27 01:41:14 G3 /Applications/Firefox.app/Contents/MacOS/firefox-bin: CGContextSetFont: invalid context
Feb 27 01:41:14 G3 /Applications/Firefox.app/Contents/MacOS/firefox-bin: CGContextSetFontSize: invalid context
Feb 27 01:41:14 G3 /Applications/Firefox.app/Contents/MacOS/firefox-bin: CGContextSetTextMatrix: invalid context
Feb 27 01:41:14 G3 /Applications/Firefox.app/Contents/MacOS/firefox-bin: CGContextSetRGBFillColor: invalid context
Feb 27 01:41:14 G3 /Applications/Firefox.app/Contents/MacOS/firefox-bin: CGContextShowGlyphsAtPoint: invalid context
Feb 27 01:41:14 G3 /Applications/Firefox.app/Contents/MacOS/firefox-bin: CGContextShowGlyphsAtPoint: invalid context
Feb 27 01:41:14 G3 /Applications/Firefox.app/Contents/MacOS/firefox-bin: CGContextShowGlyphsAtPoint: invalid context
Feb 27 01:41:14 G3 /Applications/Firefox.app/Contents/MacOS/firefox-bin: CGContextShowGlyphsAtPoint: invalid context
Feb 27 01:41:14 G3 /Applications/Firefox.app/Contents/MacOS/firefox-bin: CGContextShowGlyphsAtPoint: invalid context
Feb 27 01:41:14 G3 /Applications/Firefox.app/Contents/MacOS/firefox-bin: CGContextShowGlyphsAtPoint: invalid context
Feb 27 01:41:14 G3 /Applications/Firefox.app/Contents/MacOS/firefox-bin: CGContextShowGlyphsAtPoint: invalid context
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060227 Firefox/1.6a1

it seems the bug is fixed in the current nightly build. all attached test cases pass now. thanks!
(In reply to comment #2)
> In fact, further investigation reveals that it is not necessarily an <h?> tag
> that is necessary to trigger the bug - it is an xhtml element whose style
> includes a non-zero margin.

Yes, it does not matter, where the inline SVG is placed.

see also bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=317759
uncorrectly written text-size 

(font-szie="24px")

in attachment "Amended testcase"
Something similar seems to happen if a file contains multiple svg elements. text elements in the first svg is rendered but text elements in subsequent svg elements is not.
Regarding my earlier comment: my sample renders correctly in 1.6a1.
Blocks: tibco
Attached file Simple testcase
This testcase fails on:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

but not on:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a1) Gecko/20061204 GranParadiso/3.0a1
I see this same problem under: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1) Gecko/20061010
Firefox/2.0

However the problem seems to be related to the text element's fill not being rendered.  If I specify a stroke for the text element it is rendered as 'outlined' text.

Further to my previous post, the problem can clearly be seen to be related to the element's fill by modifying Amos' failure test case so that the text element looks like this:

                <svg:text x="0" y="20" font-size="16" stroke="blue">SVG</svg:text>
I can confirm that this bug is still unsolved, although the issue has been reported 1,5 years ago. It still exists in Firefox 2.0.0.4. It also exists in Camino.
This is fixed in 3a7
This bug will not be fixed in Firefox 2. It should be fixed in Firefox 3 however. Can anyone else on Mac confirm that this is fixed using an date trunk build from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ to test?
Managed to borrow a Mac to test myself. Confirming this is now worksforme in trunk builds.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.