Closed Bug 104881 Opened 23 years ago Closed 16 years ago

same face name with different foundary may mean different "face" on X

Categories

(Core :: Internationalization, defect)

x86
Windows NT
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX
Future

People

(Reporter: ftang, Assigned: smontagu)

Details

this is a spin off from 102623. jshin try to address that problem inside 102623 
but I think that is a Linux GFX problem and should be seperate from mail issue.

Basically, what happen is currently in GTK GFX we assume the face name mean the 
same type face design from all different foundary. This may not be true. For 
example, from 102623, we see the following four fonts all share "gothic" as face 
name in the XLFD but they are really different type face design. 

-ksh-hymjsm2-bold-r-normal--12-90-100-100-c-120-ksc5601.1987-0
-wadalab-gothic-medium-r-normal--16-*-0-0-c-*-iso8859-1
-kaist-gothic-medium-r-normal--16-160-75-75-c-160-johab-1
-daewoo-gothic-medium-r-normal--16-120-100-100-c-160-ksc5601.1987-0

jshin- I may not present the problem clearly. you probably want to specify it 
more clearly for me here.
Frank: lets say this is true. What if anything should we do?
> Basically, what happen is currently in GTK GFX we assume the face name mean the 
> same type face design from all different foundary.

  Is this the case? GTK GFX seems to differentiate between fonts
with diff. foundries but with identical family name *when* it
is given all necessary pieces of information(foundry,family,character set,
encoding). When it's handed over only family name (as is the case
with mail rendering. ref bug 102623), I don't think it can do much. (of course,
it can do some detective works to 'resurrect' missing/lost info. , but...) .
I'm refering
to FFRE model.  Brian's AFRE patch was pulled out, wasn't it?
Am I missing anything?

> Frank: lets say this is true. What if anything should we do?

   I think bug 102623 can be fixed when bug 105199 is fixed. Therefore,
IMHO, we don't have to worry about this anyway
 
In the long run,I guess  we have to consider 'additional-style' field
of XLFD which has 'lang' info in some X11 fonts ( misc-fixed-iso10646-1)
IIRC, a bug was filed for this issue  last year.


   
  

 
I still believe we should put AFRE in since this is the way that CSS spec's
fonts (not FFRE).
> I still believe we should put AFRE in since this is the way that CSS spec's
> fonts (not FFRE).

  I'm not against putting in AFRE. As I wrote in bug 102623,
At the moment, X11 font situation is 'chaotic' (MS Windows is much better
in that respect) and using only 'family name'(i.e. AFAA in a sense)
rather than AFRE/FFRE caused the trouble.  Anyway, I don't think putting
in AFRE would do much to worsen bug 102623.  ( in my particular test case,
it helped as I commented on bug 94327 ) To fix that bug, we need to fix
bug 105199 which is (semi-)orthogonal to but still related to AFRE issue.

BTW, have you looked at attachment 53094 [details] [diff] [review] to bug 94327? That might
remove some regression cases with AFRE in.

Another BTW, if we really need foundry name passed around, we may get
away with sticking foundry name to the end family name in Unix/X11.
Something like 'mincho@@kappa' might be used for *internally* generated
CSS elements.
would passing in something from which we could get a language attribute solve 
this?
Status: NEW → ASSIGNED
Target Milestone: --- → Future
--> ftang
Assignee: bstell → ftang
Status: ASSIGNED → NEW
bulk move NEW FUTURE bug to ASSIGN
Status: NEW → ASSIGNED
what a hack. I have not touch mozilla code for 2 years. I didn't read these bugs
for 2 years. And they are still there. Just close them as won't fix to clean up.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
Mass Re-open of Frank Tangs Won't fix debacle. Spam is his responsibility not my own
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Mass Re-assinging Frank Tangs old bugs that he closed won't fix and had to be
re-open. Spam is his fault not my own
Assignee: ftang → nobody
Status: REOPENED → NEW
Filter on "Nobody_NScomTLD_20080620"
Assignee: nobody → smontagu
QA Contact: teruko → i18n
X core font issue, not relevant to current code base.
Status: NEW → RESOLVED
Closed: 19 years ago16 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.