Closed
Bug 655497
Opened 12 years ago
Closed 12 years ago
Remove nsISVGGlyphFragmentLeaf
Categories
(Core :: SVG, defect)
Core
SVG
Tracking
()
RESOLVED
FIXED
mozilla6
People
(Reporter: longsonr, Assigned: longsonr)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 2 obsolete files)
28.84 KB,
patch
|
dholbert
:
review+
|
Details | Diff | Splinter Review |
nsISVGGlyphFragment leaf is only implemented by nsSVGGlyphFrame. We can remove it and make lots of methods non-virtual.
Assignee | ||
Comment 1•12 years ago
|
||
Assignee: nobody → longsonr
Attachment #530848 -
Flags: review?(dholbert)
Updated•12 years ago
|
Attachment #530848 -
Attachment is patch: true
Comment 2•12 years ago
|
||
Looks like nsISVGGlyphFragment.h has a documentation comment above the decls for GetEffecitve[XY|DxDy|Rotate]. We should probably preserve those, copying them over to nsSVGGlyphFrame.h, right?
Version: unspecified → Trunk
Assignee | ||
Comment 3•12 years ago
|
||
Sure, and I should include the removal of nsISVGGlyphFragmentLeaf in the patch too!
Assignee | ||
Comment 4•12 years ago
|
||
Copied the comments into nsSVGGlyphFrame.h
Attachment #530848 -
Attachment is obsolete: true
Attachment #530848 -
Flags: review?(dholbert)
Attachment #530854 -
Flags: review?(dholbert)
Comment 5•12 years ago
|
||
Comment on attachment 530848 [details] [diff] [review] patch >diff --git a/layout/svg/base/src/nsSVGGlyphFrame.h b/layout/svg/base/src/nsSVGGlyphFrame.h > // nsSVGGeometryFrame methods > gfxMatrix GetCanvasTM(); > >- // nsISVGGlyphFragmentLeaf interface: [...] >+ nsresult GetStartPositionOfChar(PRUint32 charnum, nsIDOMSVGPoint **_retval); >+ nsresult GetEndPositionOfChar(PRUint32 charnum, nsIDOMSVGPoint **_retval); >+ nsresult GetExtentOfChar(PRUint32 charnum, nsIDOMSVGRect **_retval); >+ nsresult GetRotationOfChar(PRUint32 charnum, float *_retval); Probably best to add something in place of "// nsISVGGlyphFragmentLeaf interface" there, or else everything below it implicitly falls under the heading of "// nsSVGGeometryFrame methods". e.g. // My own methods, or // nsSVGGlyphFrame methods, or something. > // nsISVGGlyphFragmentNode interface: > // These do not use the global transform if NS_STATE_NONDISPLAY_CHILD For logical organization, these inherited methods' declarations should probably move up top now, right? So that we've got // methods from one iface ... // methods from another iface ... // my own methods If that makes sense, maybe that move could happen in a second patch here that only moves these declarations without actually changing anything. >+nsSVGTextContainerFrame::GetGlyphFrameAtCharNum(nsISVGGlyphFragmentNode* node, >+ PRUint32 charnum, >+ PRUint32 *offset) > { >- nsISVGGlyphFragmentLeaf *fragment = node->GetFirstGlyphFragment(); >+ nsSVGGlyphFrame *fragment = node->GetFirstGlyphFrame(); Nit: in most places, your patch does s/fragment/frame/ on the naming of variables, but it looks like you might have missed this spot.
Comment 6•12 years ago
|
||
Comment on attachment 530854 [details] [diff] [review] updated patch >@@ -450,10 +450,10 @@ nsSVGTextContainerFrame::BuildPositionLi >- } else if (leaf) { >+ } else if (mContent->IsNodeOfType(nsINode::eTEXT)) { >+ nsSVGGlyphFrame *leaf = static_cast<nsSVGGlyphFrame*>(kid); Are we absolutely sure that there couldn't be any other eText type nodes here? If so, add a NS_ABORT_IF_FALSE(kid->GetType() == nsGkAtoms::svgGlyphFrame (and if not, maybe use GetType() in place of IsNodeOfType.)
Comment 7•12 years ago
|
||
(In reply to comment #6) > Are we absolutely sure that there couldn't be any other eText type nodes > here? (or rather, any other frames for eTEXT-type nodes) I'm guessing we're sure, but just want to double-check (and get your feeling on how future-proof this assumption is), since you know this text code better than I do.
Assignee | ||
Comment 8•12 years ago
|
||
Attachment #530854 -
Attachment is obsolete: true
Attachment #530854 -
Flags: review?(dholbert)
Attachment #530857 -
Flags: review?(dholbert)
Assignee | ||
Comment 9•12 years ago
|
||
(In reply to comment #7) > (In reply to comment #6) > > Are we absolutely sure that there couldn't be any other eText type nodes > > here? Yes, with the code as it is at the moment. Even so there's no harm changing to check the frame directly so that's what I've done.
Comment 10•12 years ago
|
||
Comment on attachment 530857 [details] [diff] [review] updated patch Looks great!
Attachment #530857 -
Flags: review?(dholbert) → review+
Blocks: deCOM
Assignee | ||
Updated•12 years ago
|
Keywords: checkin-needed
Comment 11•12 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/23430875e861
Status: NEW → RESOLVED
Closed: 12 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla6
You need to log in
before you can comment on or make changes to this bug.
Description
•