Closed
Bug 160697
Opened 23 years ago
Closed 19 years ago
Subscripts not lower enough
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: lapsap7+mz, Unassigned)
Details
Attachments
(6 files, 1 obsolete file)
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020802
BuildID: 2002080204
Subscripts using <sub> tags, in my opinion, aren't lower enough. Esp, if the
base font uses small font-points. Compare
x<sub>2</sub>
in Mozilla with N4 or IE and you'll see the difference.
Reproducible: Always
Comment 1•22 years ago
|
||
This problem may be windows only. This bug is repaired at once.
Please refer to Bug 9640 and
http://bugzilla.mozilla.org/show_bug.cgi?id=156943#c63.
It seems that it returned from the new version than mozilla-1.0.
In the English characters, a small character moves too small movement of the
upper or lower sides, in the CJK characters, a small character moves too much up
or down.
Comment 2•22 years ago
|
||
Comment 3•22 years ago
|
||
Attachment #99605 -
Attachment is obsolete: true
Updated•22 years ago
|
Attachment #99605 -
Attachment is obsolete: false
Comment 4•22 years ago
|
||
character coding Western <sub> not lower enough
<sup> good
Jpapanese <sub> good
<sup> too higher
See also Bug 112502.
Comment 5•22 years ago
|
||
Please also refer to
http://bugzilla.mozilla.org/show_bug.cgi?id=156943#c64.
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Updated•19 years ago
|
Assignee: samir_bugzilla → nobody
Severity: trivial → normal
Component: XP Apps → Layout: Fonts and Text
Product: Mozilla Application Suite → Core
QA Contact: pawyskoczka → layout.fonts-and-text
Comment 6•19 years ago
|
||
Comment 7•19 years ago
|
||
It seems that subscripts are not lower enough in English but they are too lower in Japanese. I think that it is better for offset of the scripts using x-height than using font metrics. I chose 40% of xHeight.
Attachment #208508 -
Flags: review?(rbs)
Updated•19 years ago
|
Attachment #208508 -
Attachment description: path → patch
Comment 8•19 years ago
|
||
Comment 9•19 years ago
|
||
Comment 10•19 years ago
|
||
Comment 11•19 years ago
|
||
You were driving bug 112502 recently and made the case for the existing code. Why the U-turn?
Also, when a value is rightly set by font-designers, that's what they want it to be. Overriding means that we are telling them that know their own fonts better than them (and discourage them from honoring the contract in future fonts).
If you must adjust in the case of unset metrics, why not do:
if (oMetrics.otmptSubscriptOffset.y == 0 || oMetrics.otmptSubscriptOffset.y >= metrics.tmAscent)
- mSubscriptOffset = mXHeight; // XXX temporary code!
+ mSubscriptOffset = mXHeight * 0.4f; // 40% of xHeight
else
mSubscriptOffset = NSToCoordRound(oMetrics.otmptSubscriptOffset.y * dev2app);
Comment 12•19 years ago
|
||
For example, if font-size is 19 pixels, otmpSubscriptSize is 10 pixels and otmpSubscriptOffset is 2 pixels, however, actually used font-size for subscripts is 15 pixels. I think that otmpSubscriptOffset should not be used directly since actually used font-size differs from otmpSubscriptSize.
case of Times New Roman:
metrics
tmHeight 19 15 27
tmAscent 15 12 21
tmDescent 4 3 6
oMetrics
otmpSubscriptSize 10 16
otmpSubscriptOffset 2 3
Comment 13•19 years ago
|
||
Comment on attachment 208508 [details] [diff] [review]
patch
I think that the offset should be calculated from otmptSubscriptSize and otmptSubscriptOffset, based on the font-size of the subscripts.
Attachment #208508 -
Attachment is obsolete: true
Attachment #208508 -
Flags: review?(rbs)
Comment 14•19 years ago
|
||
[Typo... Overriding means that we are telling them that [WE] know their own fonts]
When I saw your comment 12, I started to wonder if layout was picking the right font-metrics (since <sup>/<sub> entails font-size: smaller in the sub/superscript, and it would be wrong to use the offsets from the smaller font). But I have now checked nsLineLayout::VerticalAlignFrames() and it is rightly using the parent's font-metrics to determine the offsets of the sub/superscript.
I do not actually dislike attachment 208509 [details] (original) since it is a recent iteration from what you did in bug 112502, and would go with what I suggested in comment 11 if you have to.
Comment 15•19 years ago
|
||
> and would go with what I suggested in comment 11 if you have to.
I do not have a plan to adjust the offset for the special case of Japanese subscript since the offset is in range (metrics.tmAscen > oMetrics.otmptSubscriptOffset.y > 0) as to our usual font.
> I do not actually dislike attachment 208509 [details] [edit] (original)
Is this bug WONTFIX?
Comment 16•19 years ago
|
||
I think so. The other Gfx ports are not tampering with the metrics either.
[Perhaps, the real issue is to use something other than "font-size: smaller" for <sub>/<sup>. This way, layout could use the right font-size (otmptSubscriptSize/otmptSuperscriptSize) specifically recommended by the font-designer for the sub/superscript. But that's more involved because we will then need to support things like "font-size: -moz-subscript" and "font-size: -moz-superscript", and add new APIs to fetch otmptSubscriptSize/otmptSuperscriptSize... Better to see if cairo will fare better.]
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•