Closed
Bug 15989
Opened 25 years ago
Closed 25 years ago
Text describing images before they load is reversed
Categories
(Core :: Layout, defect, P3)
Tracking
()
M17
People
(Reporter: moshev, Assigned: ftang)
References
Details
Attachments
(5 files)
When you load a page with <img src></img> tag,
that have a textual description for image (the text appearing
before the image loads), the text appears in revers order
while the image loads (xuniL) for Linux
(While it's good for BiDi support :),....)
Updated•25 years ago
|
Comment 1•25 years ago
|
||
Changing to Layout, for now, anyway.
I'm not seeing this on Linux viewer 1999-10-08-08-M11. Could there be some
detail of your system configuration (bidi support?) causing this? What build
are you using? Could you attach a screenshot?
Attached two screenshots as requested,
The build is 1999100808 it's m10 release,
(I wish i had BiDi on linux, there is however
none available :(
Forgot this one, it's a mixed RH/Mandrake 6.0-1 with glibc2.1,
and Linux 2.2.5
What dependencies do you want me to check?
Comment 7•25 years ago
|
||
I'm not seeing this in the M10 release. I can also see from the second
screenshot that you're not seeing bug 12217 and I am. What font server are you
using?
I use xfs with xfsft built into it (which is what comes with RH 6.0), with some
TT fonts added.
Comment 8•25 years ago
|
||
I think the reason I'm not seeing the bug is that I see bug 12217 and you
don't. The problems of RTL text in your second screenshot all occur around the
character ™ in the Arial font, with the line split into two halves around
that character. I'll look at the others too in a minute...
Comment 9•25 years ago
|
||
There's no such pattern on the other examples, so only the second example makes
some degree of sense to me.
I have to say this looks more like some sort of an i18n/font handling bug.
cc:ing erik@netscape.com, author of Unix font selection code.
Reporter | ||
Comment 10•25 years ago
|
||
Reporter | ||
Comment 11•25 years ago
|
||
Reporter | ||
Comment 12•25 years ago
|
||
I am not sure how to test for the font server,
i onced installed xfs/xftt, but the override
it with RH 6 upgrade, so now
i am not sure what's running, in "ps axw" I don't see it.
Tell me if you need any other info from my system.
(like some specific fonts or output of xlsfonts)
Comment 13•25 years ago
|
||
Frank, any ideas? (The text is being reversed.)
Comment 14•25 years ago
|
||
I think this is a gfx rendering problem.
Kevin, who owns the gfx specific rendering code? And what is the component?
Updated•25 years ago
|
Assignee: kmcclusk → ramiro
Comment 15•25 years ago
|
||
My guess is the problem is in the nsRenderingContextGTK::DrawString.
There is code which will render the string one character at a time, by placing
the coordinates of the character through a transform. It's possible that the
transform is reflecting the coordinates,
S_IMETHODIMP
nsRenderingContextGTK::DrawString(const char *aString, PRUint32 aLength,
nscoord aX, nscoord aY,
const nscoord* aSpacing)
...
if (nsnull != aSpacing) {
// Render the string, one character at a time...
const char* end = aString + aLength;
while (aString < end) {
char ch = *aString++;
nscoord xx = x;
nscoord yy = y;
mTMatrix->TransformCoord(&xx, &yy);
::gdk_draw_text(mSurface->GetDrawable(), mCurrentFont,
mSurface->GetGC(),
xx, yy, &ch, 1);
x += *aSpacing++;
}
Ramiro and Pavlov own the nsRenderingContextGTK component, but it may be XPCODE
thats to blame for messing up the tranform.
Comment 16•25 years ago
|
||
It doesn't really look like a transform bug, because the letter-spacing is not
messed up (unless the transform would also cause it to position by the other
edge of the letter). And also, could a transform cause the two halves of the
sentence to be split, like the third line from the end in attachment 2061 [details], which
is shown like:
ABCDEFG
LKJIHNM
OPQRSTU?
It really does look more like an i18n bug.
Updated•25 years ago
|
Assignee: ramiro → waqar
Comment 17•25 years ago
|
||
waqar: this needs more investigation, it might be a layout or more likely i18n
bug.
erik can help with i18n issues on unix.
Comment 18•25 years ago
|
||
Resetting QA contact from leger.
URL: http://lwn.net/daily
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Comment 19•25 years ago
|
||
I am not seen this happen as well. I am going to close this as works for me.
Comment 20•25 years ago
|
||
I think that's a bad idea. There's some font bug that's preventing the right
font from showing. When that font is visible, I think the bug will show up.
A bug should be filed on the fonts showing up without Arial...
Comment 21•25 years ago
|
||
Actually, the font thing is a residual style bug. So how did it work before?
Could the original reporter of this bug comment? If you still see the bug,
could you make a simplified test case? Could you figure out which font on your
system is being used? Could your Arial font be a different version (a Hebrew
version from Microsoft)?
Please don't verify this bug yet. I think it could be something
system-specific...
Reporter | ||
Comment 22•25 years ago
|
||
I originally had TTF's from Hebrew version of MS Windows,
but lately i played a lot with the fonts on my system, and no
i don't see it anymore, but i think the bug is still there, cause
before i played with fonts i had this
problem on almost any page i visited.
I think it should be left open untill font-preferences are working, then
i could try it with different fonts on my system and tell if it's still there
with some fonts.
Updated•25 years ago
|
Resolution: WORKSFORME → ---
Comment 23•25 years ago
|
||
Adding dependency on 8801 (font prefs). Re-opening.
Updated•25 years ago
|
Assignee: waqar → ftang
Status: REOPENED → NEW
Comment 24•25 years ago
|
||
Frank, you added some bidi hacks to Unix gfx. Could you double-check this?
Comment 25•25 years ago
|
||
I've come across what I believe may be another issue caused by the same root
problem as described in this bug report. If you view the page at:
http://www.unicode.org/iuc/iuc10/x-utf8.html
you'll see that there is a section in Hebrew (ignore the Yiddish one). In this
section, there are a few words that aren't in Hebrew. However, these are
incorrectly rendered RTL instead of LTR. For example, '1997' is rendered as
'7991'. Therefore, I'm thinking that this would be ultimately a similar example
of the problem reported in this bug. Right? If not, please let me know directly
so that I may file a new bug.
Reporter | ||
Comment 26•25 years ago
|
||
When i saw the problem i saw exactly what you describe on many hebrew pages,
so i think it's the same problem. Now, i don't see the problem including
on the page you are reffering to, however the hebrew words on this page
are displayed in incorrect order. I am not sure if this is because this page's
layout is logical. If it is, then it is strange that mozilla is able to
correctly reverse the letters inside the words, is there anyone that implemented
a partial RTL-LTR for mozilla???
Comment 27•25 years ago
|
||
The problem cpratt described sounds like a separate bug. This bug should be for
creation of RTL text within an entirely LTR document due to the presence of RTL
fonts.
Comment 28•25 years ago
|
||
Bug 21022 now contains the problem I described in an earlier comment. My apologies for the intrusion!
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 29•25 years ago
|
||
What happen is the following- moshev have the following line in his
XF86config (id=2066)
FontPath "/usr/X11R6/lib/X11/fonts/hebrew"
Therefore, he have a hebrew font in his font path. Somehow the img fallback code
use the hebrew font. In the hebrew font hack I add to gfx, I assume the hebrew
font won't be in the first item of the font list and just assume all the ASCII
character will be handle by non Hewbrew/Arabic fonts. Therefore, I revere
everything. One quick and dirty way to solve it is to clear the bits in the 8K
bits array for the hebrew/Arabic fonts.
Target Milestone: M14 → M17
Comment 30•25 years ago
|
||
I am having this same problem with M13 under linux. I have some hebrew fonts
installed, but thanks to the font-prefs problem i can't find which one exactly
causes the problem and remove it. I know however the "bible" font is the one
which font-prefs picks by default on my system. getting new 13G hd soon so i
might be able to build a new mozilla with the font-prefs bug fix soon (a bit
too short on disk space right now). One thing i notice is that this reverses
any line cotaining high-ascii chars on it which can be quite annoying, therefor
i suggest fixing this earlier then M17, since right now i have to open netscape
4.7 whenever i view a a page with more then 2 or 3 lines containing high ascii.
Assignee | ||
Comment 31•25 years ago
|
||
dup of 29498. Will fix tonight.
*** This bug has been marked as a duplicate of 29498 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•