Closed
Bug 655497
Opened 14 years ago
Closed 14 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•14 years ago
|
||
Assignee: nobody → longsonr
Attachment #530848 -
Flags: review?(dholbert)
Updated•14 years ago
|
Attachment #530848 -
Attachment is patch: true
Comment 2•14 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•14 years ago
|
||
Sure, and I should include the removal of nsISVGGlyphFragmentLeaf in the patch too!
Assignee | ||
Comment 4•14 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•14 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•14 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•14 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•14 years ago
|
||
Attachment #530854 -
Attachment is obsolete: true
Attachment #530854 -
Flags: review?(dholbert)
Attachment #530857 -
Flags: review?(dholbert)
Assignee | ||
Comment 9•14 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•14 years ago
|
||
Comment on attachment 530857 [details] [diff] [review]
updated patch
Looks great!
Attachment #530857 -
Flags: review?(dholbert) → review+
Blocks: deCOM
Assignee | ||
Updated•14 years ago
|
Keywords: checkin-needed
Comment 11•14 years ago
|
||
Status: NEW → RESOLVED
Closed: 14 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
•