Closed
Bug 95721
Opened 24 years ago
Closed 23 years ago
Add GTK+/Xlib support for for getting actual string height (GetDimensions)
Categories
(Core :: Internationalization, defect)
Tracking
()
VERIFIED
FIXED
mozilla0.9.5
People
(Reporter: bstell, Assigned: bstell)
References
Details
(Keywords: intl)
Attachments
(9 files)
bug 74189 is adding code to actually measure a strings height.
This would help text not overlap when the glyph fill in code ends up picking
a larger glyph.
nsFontMetricsGTK.cpp needs to be modified to add similar code to the new
code added to nsFontMetricsWin.cpp.
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.4
Assignee | ||
Comment 3•24 years ago
|
||
How complete is attachment 46317 [details]?
ie: if it were added to the tree would it solve this bug?
The complete patches to apply are those that I recently attached to bug 74186:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=46323
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=46324
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=46325
Assignee | ||
Comment 5•24 years ago
|
||
So you have done all the work and are looking for a review?
Yes, nearly all. I am looking for testing and review on your system (with
possible corrections that may ensue on the patch that affected the GTK part).
[Also, on a related matter, I would appreciate if you emulate what I did for
the support of the list of multiple fallback fonts in nsFontMetricsWin so that,
at least, both platforms will be in sync. (If you apply the patch, you will see
the GenericFontEnumCallback stuff more clearly).]
In particular the handling of the min-size in GfxGTK wouldn't be necessary
anymore since it is now handled from within the Style System. This can be tested
for example by trying a large value of the min-size and seeing how the sidebar
contents are enlarged while the tabs themselves remain unchanged.
Assignee | ||
Updated•24 years ago
|
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Cc:ing Roland.Mainz@informatik.med.uni-giessen.de for the Xlib corner.
nsIRenderingContext::GetDimensions() is needed on all flavors of GFX.
+nsRenderingContextGTK::DrawString2(const PRUnichar* aString, PRUint32 aLength,
nscoord aX, nscoord aY,
PRInt32 aFontID,
const nscoord* aSpacing)
@@ -1458,11 +1550,6 @@
nscoord x = aX;
nscoord y;
Sould be...
nscoord y = aY;
Comment 10•23 years ago
|
||
Uhm... OK... TMP - Too Many Patches... :-)
Which attachments are required to patch a GTK+-toolkit Zilla ?
Summary: add Gtk support for for getting actual string height (GetDimensions) → Add GTK+/Xlib support for for getting actual string height (GetDimensions)
Comment 11•23 years ago
|
||
Given that there has been a lot of checkins since my earlier diffs, the patches
are likely out of sync now. Let me update my build to the tip, and I will
provide other patches shortly -- that's why there are TMP... and the fact that
the added functionality is much involved and requires several iterations to get
things right doesn't help in that respect either.
Comment 12•23 years ago
|
||
Comment 13•23 years ago
|
||
Comment 14•23 years ago
|
||
I am going to attach the full "tip-ready" patches for application on bug 74186.
Comment 15•23 years ago
|
||
gisburn, I just attached the latest patches to bug 74186, inlcuding a tentative
port to Xlib. I am eager to hear the outcome of your testing on Xlib (and
possibly GTK?). The needed patches are:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=46957
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=46958
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=46961
Comment 16•23 years ago
|
||
Typo in xlib (from copy-pasting...)
NS_IMETHODIMP
+nsRenderingContextGTK::DrawString(const char *aString, PRUint32 aLength,
Of course, the namespace should be nsRenderingContextXlib.
Comment 18•23 years ago
|
||
I need two or three days until I have a fresh&clean build to test this one ...
is that acceptable ? Or should I swing the whips on myself ? :-)
Comment 19•23 years ago
|
||
By then the pacthes would have been long outdated and I will have to attach even
more patches :( My suggested way of testing is actually to duplicate your trees
(if you don't have many trees already) and then try the stuff into one.
Comment 20•23 years ago
|
||
Comment 21•23 years ago
|
||
Assignee | ||
Comment 22•23 years ago
|
||
rbs: now that bug 99010 is checked in should we close this?
Comment 23•23 years ago
|
||
Yes, resolving as FIXED to to get it off the radars.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 24•23 years ago
|
||
Switching qa contact to ylong for now. Yuying, please check with ftang if you
need a test case for verifying this.
Keywords: intl
QA Contact: andreasb → ylong
Assignee | ||
Comment 25•23 years ago
|
||
Assignee | ||
Comment 26•23 years ago
|
||
if one sets the min-size for japanese in unix.js to 6
pref("font.min-size.variable.ja", 6);
pref("font.min-size.fixed.ja", 6);
and displays the test case, attachment 51742 [details],
without this fix the test case will have glyphs touching
with this fix the test case will not have glyphs touching
Comment 27•23 years ago
|
||
Thanks, Brian!
The build with bug 99010 fix checked in is not overlapping any more but still
toughed, by looking into Brian's test case.
Did we really resolved this problem?
Comment 28•23 years ago
|
||
Comment 29•23 years ago
|
||
Comment 30•23 years ago
|
||
Do you also have another screenshot for another application/editor that is
rendering the same text?
Comment 31•23 years ago
|
||
Comment 32•23 years ago
|
||
Interesting comparisons... Either the fonts are not telling the full story or it
is yet again the dilemma of whether the external leading (or some approximation
thereof) should be included in the metrics or not.
Cc:ing some people with whom we discussed this in bug 76097.
Now that each nsFont[Win|GTK] keeps its own metrics, it might be possible to
special case certain Japanese fonts without regressing ASCII documents at all,
e.g, nsFontGTK::mMaxAscent can be tweaked a little bit in the case where it
belongs to a Japanese font and it is known that the direct metrics returned by
the font are not satisfactory. (From there on, the supporting infrastructure of
GetTextDemensions() will cater for the rest whilst the nsIFontMetrics API will
continue to be associated to the existing ASCII metrics.)
Comment 33•23 years ago
|
||
BTW, I wonder why N6 glyphs are bigger than in Nav4.x (using '1' as reference
enables to see marked differences) -- shouldn't all the glyphs be identical to
begin with.
Assignee | ||
Comment 34•23 years ago
|
||
4.7 may be selecting a Japanese font that has a smaller size.
Comment 35•23 years ago
|
||
I'm re-openning it for now, please mark it as resolve when we have better
solution or if we can get good envidence.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Comment 36•23 years ago
|
||
Let's move the ongoing data to a separate bug given that the primary issue of
this bug was to hook GetTextDimensions() to GTK/Xlib and it was resolved. By
design, the metrics returned come from the fonts themselves as originally
intended.
It appear that adding an extra leading may be needed, and so it is worth having
a separate, focussed bug, where the amount of leading and other details could be
agreed upon.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Target Milestone: mozilla0.9.6 → mozilla0.9.5
Comment 37•23 years ago
|
||
Mark as verified according rbs's last comments.
Maybe after bug 96535 fixed, we don't even need adding an extra leading.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•