Open
Bug 80687
Opened 24 years ago
Updated 2 years ago
Need a way to control what goes in gFamilyNameTable
Categories
(Core :: XUL, defect)
Core
XUL
Tracking
()
NEW
Future
People
(Reporter: tvl, Unassigned)
References
Details
in nsFontMetricsGTK, the mappings in gFamilyNameTable for arial, courier new. and times new roman are all hardcoded. There needs to be a way that and embeddor can provide what these mappings should be (pref, compile time, something).
Updated•24 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reassigning to XP widgets to gather suggestions on the best way this should be done.
Assignee: adamlock → trudelle
Component: Embedding APIs → XP Toolkit/Widgets
QA Contact: mdunn → jrgm
Comment 3•24 years ago
|
||
Who owns this stuff? GFX doesn't have a bugzilla component, and I see lots of names giving r= in the code, but nobody on my team. ->ftang, cc bstell
Assignee: trudelle → ftang
Comment 4•24 years ago
|
||
reassign to bstell. I am not sure how high the priority should be. we also need to watch start time performance.
Assignee: ftang → bstell
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → Future
gisburn, let's do this rbs: how does nsIPersistentProperties deal with unicode property files? Some CJK font aliases would definitely have to have Unicode names
*** Bug 107515 has been marked as a duplicate of this bug. ***
Comment 7•23 years ago
|
||
I can implement this (but in 0.9.7, my 0.9.6 ToDo list is far too large now) ...
There is very nice code dealing with a very similar problem in Win32 gfx/, using nsIPersistentProperties. Looks like PersistentProperties will handle unicode properly, using \xxxx escapes. nsFontMetrics*::TryAliases would have to be adjusted too.
>how does nsIPersistentProperties deal with unicode property files? &#xNNNN; -> \uNNNN (e.g., http://lxr.mozilla.org/seamonkey/find?string=mathfont) Beware: in the "name = value" pair, the name is left as-is, while the value is mapped to Unicode. So if you put \uNNNN in the "name" part, it will be kept as-is, i.e., the equivalent 6-character ASCII string: '\', 'u', and digits... but if you put \uNNNN in the "value" part, it is converted to the single corresponding Unicode character.
Comment 13•18 years ago
|
||
Is this bug still considered valid? jag are you still working on this?
Updated•16 years ago
|
Assignee: jag → nobody
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•