[Bug 16697] Unicode combining characters are difficult to edit in some browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=16697 Niklas Laxström niklas.laxst...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #27 from Niklas Laxström niklas.laxst...@gmail.com 2009-07-28 15:38:48 UTC --- Implemented solution I proposed above in r53874. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16697] Unicode combining characters are difficult to edit in some browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=16697 --- Comment #26 from Niklas Laxström niklas.laxst...@gmail.com 2009-06-19 11:49:31 UTC --- To have something concrete I propose to add css override for languages with no good monospace font(s). The css would use serif or sans-serif font style for textareas. There should also be possibility to users switch back to monospaced. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16697] Unicode combining characters are difficult to edit in some browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=16697 --- Comment #23 from Andrew Cunningham lang.supp...@gmail.com 2008-12-29 12:58:28 UTC --- (In reply to comment #22) Betawiki has a gadget that allows you to cycle from monospace, to sans, to serif. This shows that monospace breaks the usability of some of the languages we support. The only logical conclusion is to change from monospace to an other style of fonts. No catch-22 for me. If something is not usable, we use something else. This WILL work for Firefox, Opera and Safari. Internet Explorer and Chrome are both currently broken; IE shows the wrong character Chrome shows no character. For lesser used languages, this approach assumes: 1) End users have installed all language support available within the OS. Currently the only OS that I know of that installs all language support available by default is Windows Vista (maybe macOS too, don't know enough about MacOS to say). Windows XP and older versions of Widows as well as most, if not all Linux distros only install a minimal set of language support. Full language support has to be specified during the install or installed afterwards. 2) End users have downloaded and installed appropriate fonts to cover all the languages covered by Betawiki. Since lesser used languages may not be supported 3) Generic font families assume that the end user has modified the default browser generic fonts per writing script to use appropriate fonts 4) That appropriate (monospaces, serif, sans-serif) fonts are available for the language in question -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16697] Unicode combining characters are difficult to edit in some browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=16697 --- Comment #25 from Andrew Cunningham lang.supp...@gmail.com 2008-12-29 22:38:17 UTC --- (In reply to comment #23) 4) That appropriate (monospaces, serif, sans-serif) fonts are available for the language in question A clarification on my comment, with respect to monospaced fonts. It is important to note that there are few monospaced fonts (if any) that support various lesser used languages. And for many writing scripts monospaced fonts are inappropriate. Looking at windows environment for instance, you'll find that for most scripts there isn't a monospaced font available. For various dubious reasons certain browsers default to monospaced fonts for displaying text in certain html elements. This is poor internationalisation. It doesn't scale in a truly multilingual environment. Using generic font families can be a problem when you are developing or maintaining a truly multilingual environment. They are useful in themes and skins, so that the themes or skins can be made language neutral, but the themes or skins then need to be overlaid with language specific styling to ensure that all text has a chance of displaying. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16697] Unicode combining characters are difficult to edit in some browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=16697 --- Comment #22 from Gerard Meijssen gerard.meijs...@gmail.com 2008-12-27 13:41:31 UTC --- Betawiki has a gadget that allows you to cycle from monospace, to sans, to serif. This shows that monospace breaks the usability of some of the languages we support. The only logical conclusion is to change from monospace to an other style of fonts. No catch-22 for me. If something is not usable, we use something else. This WILL work for Firefox, Opera and Safari. Internet Explorer and Chrome are both currently broken; IE shows the wrong character Chrome shows no character. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16697] Unicode combining characters are difficult to edit in some browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=16697 --- Comment #20 from Gerard Meijssen gerard.meijs...@gmail.com 2008-12-25 12:23:14 UTC --- MediaWiki experience with a change for Bug 1941 showed that a change FROM monospace removed the ability for Safari to work properly. It is likely that the change TO monospace for the edit screen for FireFox and IE will make these browsers work as well for these browsers. Thanks, GerardM -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16697] Unicode combining characters are difficult to edit in some browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=16697 --- Comment #17 from Andrew Cunningham lang.supp...@gmail.com 2008-12-21 23:49:42 UTC --- (In reply to comment #12) The MediaWiki default is not to specify fonts at all for any language. Which is actually a good approach, stylesheets should be language neutral as much as possible. But there are two scenarios for content: 1) all content in a single page is monolingual - in which case all is fine 2) content is predominately in one language, but contains words, phrases, quotes from other languages - this is a more problematic scenario. Since it would require different fonts to be used to display different languages. IN most the major languages that have full OS support current approach works fine. OS font-linking/switching and browser based approaches work fine. But for lesser used languages where there is no official OS support, things become more problematic, since different fonts may need to be specified for that language as distinct form the text of the surrounding page. The easiest and simplest approach is the use of language tagging in the markup and then users can tie their own css rules to the language markup. Essentially the nature of Wikipedia content, means that the first fall back is OS and web browser fallback mechanisms, the second fall back is end user CSS overrides. For monolingual content in a language specific wiki, its possible to have some sensible CSS rules in a language specific customisations to monobook.css For content that includes words and phrases in other languages, the most sensible approach is language markup, this allows CSS rules to be created for wiki specific monobook.css or user specific CSS rules. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16697] Unicode combining characters are difficult to edit in some browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=16697 --- Comment #18 from Andrew Cunningham lang.supp...@gmail.com 2008-12-22 00:01:54 UTC --- (In reply to comment #13) A solution should not be confined to the ln.wikipedia. It should also work on Commons or Meta. When CSS rules are supposed to be language specific, then the support of the CSS should be based on what language is selected in the user preferences. But a user may have their preferences set to one language and may also work in other languages. So that approach will work in many cases but not in all. MediaWiki is software that should work for any language. It does only need to specify fonts that work. It does work for any language. But for languages not supported officially by major OS vendors, things have always been more problematic, the advent of Unicode doesn't change that. There are limitations to web browsers, operating system support, and even HTML and CSS specifications. In an ideal world there would be comprehensive Latin script OpenType fonts available by default within an OS. But even is there are, web browsers and CSS provide no way to control which OpenType features are used for specific HTML documents. So its impossible to use a single Latin script font for all Latin script languages, even if it has language specific features and alternative glyphs for various languages. Browsers and CSS provide no way to access or control these features. The best approach I've found for working with multiple scripts and languages (and some projects i've worked with up to 100 languages) is to have the main CSS rules be language neutral, tag primary language of a document, allow mechanisms for authors to indicate/markup up change of languages, allow language specific styling independent of the main styling for the theme/skin, and allow users to override/control aspects of the language specific styling. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16697] Unicode combining characters are difficult to edit in some browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=16697
Aryeh Gregor simetrical+wikib...@gmail.com changed:
What|Removed |Added
Severity|blocker |major
--- Comment #12 from Aryeh Gregor simetrical+wikib...@gmail.com 2008-12-20
23:40:51 UTC ---
(In reply to comment #11)
For ln.wikipedia.org current css rules controlling font display would be
#content, #bodyContent {
font-family:'DejaVu Sans','Segoe UI','Lucida Sans Unicode','Lucida
Grande',Tahoma,'Arial Unicode MS','Lucida Sans',Verdana,sans-serif;
}
If those are wrong, bring it up at [[ln:MediaWiki talk:Monobook.css]], not
here. We (developers/sysadmins) don't have control over what CSS rules sysops
choose to add for their own wikis. The MediaWiki default is not to specify
fonts at all for any language.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16697] Unicode combining characters are difficult to edit in some browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=16697 --- Comment #13 from Gerard Meijssen gerard.meijs...@gmail.com 2008-12-20 23:54:08 UTC --- A solution should not be confined to the ln.wikipedia. It should also work on Commons or Meta. When CSS rules are supposed to be language specific, then the support of the CSS should be based on what language is selected in the user preferences. MediaWiki is software that should work for any language. It does only need to specify fonts that work. Thanks, GerardM -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16697] Unicode combining characters are difficult to edit in some browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=16697 --- Comment #10 from Brion Vibber br...@wikimedia.org 2008-12-19 20:31:09 UTC --- In what way are they inadequate, specifically, and what would you recommend as a change? (Consider downloadable web fonts to be a potential option, though that brings difficulties with it.) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16697] Unicode combining characters are difficult to edit in some browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=16697
--- Comment #11 from Andrew Cunningham lang.supp...@gmail.com 2008-12-20
06:04:01 UTC ---
For ln.wikipedia.org current css rules controlling font display would be
#content, #bodyContent {
font-family:'DejaVu Sans','Segoe UI','Lucida Sans Unicode','Lucida
Grande',Tahoma,'Arial Unicode MS','Lucida Sans',Verdana,sans-serif;
}
Taking each font in turn:
DejaVu Sans - OK for Lingala
Segoe UI - I'd need to test, should be ok, but Vista font
Lucinda Sans Unicode - cannot correctly render all Lingala characters, no mark,
makmk OpenType features
Lucinda Grande - Mac OS font, don't know if this supports Lingala or not, would
need to test.
Tahoma - version 3.0.6 (on WinXP) does not support Lingala, Version 5.0 may
support Lingala, would need to test.
Arial Unicode MS - cannot correctly render all Lingala characters, no mark,
makmk OpenType features
Lucinda Sans - support for lingala unknown
Verdana - version 3.0.6 (on WinXP) does not support Lingala, Version 5.0 may
support Lingala, would need to test.
General rule of thumb for CSS font family fallback choose most appropriate
non-core fonts first, then fall back to core OS fonts
So a rule like
#content, #bodyContent {
font-family:'DejaVu Sans','Segoe UI','Lucida Grande',Tahoma,Verdana,sans-serif;
}
would be better
Although best would be to add other download able fonts suitable for African
languages:
#content, #bodyContent {
font-family:'DejaVu Sans','Charis SIL','Gentium Book Basic','Liberation
Sans','Doulos SIL','African Sans serif','African Sans','Segoe UI','Lucida
Grande',Tahoma,Verdana,sans-serif;
}
depending on Tahoma and Verdana v. 5.0 support for Lingala, i'd be tempted to
strip these from the CSS rules, may or maynot help Vista users, but could cause
problems for users on older windows and Mac users who have an older version of
MS Office installed.
Segoe UI and Lucinda Grande. Would need to test these when i'm back in the
Office on Monday.
Also I likes using monospaced fonts for textareas, and i find its sueful to
explicity state font rules for the textarea element, so
#content, #bodyContent, textarea {
font-family:'DejaVu Sans','Charis SIL','Gentium Book Basic','Liberation
Sans','Doulos SIL','African Sans serif','African Sans','Segoe UI','Lucida
Grande',Tahoma,Verdana,sans-serif;
}
might work better.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16697] Unicode combining characters are difficult to edit in some browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=16697 Brion Vibber br...@wikimedia.org changed: What|Removed |Added CC||br...@wikimedia.org Summary|MediaWiki does not support |Unicode combining characters |extended Latin script |are difficult to edit in |properly|some browsers --- Comment #6 from Brion Vibber br...@wikimedia.org 2008-12-18 23:53:49 UTC --- This ɔ́ is a Unicode compound character, consisting of a base character (ɔ) followed by a combining accent ( ́). The bad news is that plenty of software is a little spotty about handling such characters cleanly. In this case, that means the browsers and the fonts. Pasting ɔ́ into Firefox 3 on my Mac seems to work fine. If it's not functioning in other current browsers, bug reports should be filed in the appropriate locations so it can be fixed for future versions. I'm not sure there's much else to be done on our end... working with the characters relies on them actually being supported by the browsers! -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16697] Unicode combining characters are difficult to edit in some browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=16697 --- Comment #7 from Gerard Meijssen gerard.meijs...@gmail.com 2008-12-19 00:10:00 UTC --- (In reply to comment #6) Thanks Brion, both FF and Chrome show Mbɔ́tɛ! properly in final form on the Wiki. http://meta.wikimedia.org/wiki/User:GerardM/Lingala IE does not. In edit mode, FF shows the diacritic separately while Chrome does not know how to handle it. So there is a difference between final form and edit.. Is there a difference in the font support indicated by MediaWiki ? Thanks, GerardM -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16697] Unicode combining characters are difficult to edit in some browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=16697 --- Comment #8 from Brion Vibber br...@wikimedia.org 2008-12-19 00:24:42 UTC --- This is entirely dependent on the text rendering and font support of the browser and the operating system it's running on. Some quick tests on my boxes: Safari 3 / Mac 10.5 -- edit good, page good Safari 3 / Win XP -- edit good, page good Firefox 2 / Ubuntu 7.10 -- edit good, page good Firefox 3 / Mac 10.5 -- edit good, page good Firefox 3 / Win XP -- edit and page both show base and comining character ok, but incorrectly spaced (not composited into a single visible glyph) Chrome / Win XP -- edit and page both shown with correct composition but a big box instead of the base character IE 7 / Win XP -- edit and page both show good base character followed by a totally unrelated character (looks like hebrew or something, not the expected acute accent at all!) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
