[Desktop-packages] [Bug 1866038] [NEW] By default install Noto fonts for Unicode ranges not already covered by default
Public bug reported: There is currently movement towards protecting browser users from font fingerprinting. This means refusing, by default, to load user-installed fonts, which makes the set of fonts that each OS installs by default even more important than before. Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1582687 W3C CSS WG issue: https://github.com/w3c/csswg-drafts/issues/4497 Currently, Windows 10, macOS, Android, Chrome OS, and, to a lesser extent, Fedora provide broader installed-by-default Unicode coverage than Ubuntu. Examples of living scripts that have enough active users to make it to the list at https://en.wikipedia.org/wiki/List_of_writing_systems#List_of_writing_scripts_by_adoption but are not supported by default in Eoan include Javanese, Sundanese, Batak, Balinese, Modern Yi, Mongolian, and New Tai Lue. Egyptian hieroglyphs is an example of a dead script the Eoan doesn't support but Windows 10, macOS, Chrome OS, and Android do support. To remedy this with minimal disk space impact, I suggest the same approach that Apple took. Apple bundles with macOS those Noto fonts that cover scripts that were not already covered by the previous installed- by-default set of fonts on macOS. In the macOS case, the on-disk footprint of the Noto fonts that were required to take macOS to Android/Chrome OS-competitive Unicode coverage was only a couple of megabytes. (The fonts are hidden in /Library/Application Support/Apple/Fonts/Language Support/.) In the case of Ubuntu, the set of Noto fonts required to reach the Chrome OS / Android level of script coverage is a bit larger than in the macOS case but should still be manageable. Please install, by default, those Noto fonts that provide support for scripts that are not properly supported by the fonts that Ubuntu already installs by default. ** Affects: fonts-noto (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to fonts-noto in Ubuntu. https://bugs.launchpad.net/bugs/1866038 Title: By default install Noto fonts for Unicode ranges not already covered by default Status in fonts-noto package in Ubuntu: New Bug description: There is currently movement towards protecting browser users from font fingerprinting. This means refusing, by default, to load user- installed fonts, which makes the set of fonts that each OS installs by default even more important than before. Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1582687 W3C CSS WG issue: https://github.com/w3c/csswg-drafts/issues/4497 Currently, Windows 10, macOS, Android, Chrome OS, and, to a lesser extent, Fedora provide broader installed-by-default Unicode coverage than Ubuntu. Examples of living scripts that have enough active users to make it to the list at https://en.wikipedia.org/wiki/List_of_writing_systems#List_of_writing_scripts_by_adoption but are not supported by default in Eoan include Javanese, Sundanese, Batak, Balinese, Modern Yi, Mongolian, and New Tai Lue. Egyptian hieroglyphs is an example of a dead script the Eoan doesn't support but Windows 10, macOS, Chrome OS, and Android do support. To remedy this with minimal disk space impact, I suggest the same approach that Apple took. Apple bundles with macOS those Noto fonts that cover scripts that were not already covered by the previous installed-by-default set of fonts on macOS. In the macOS case, the on- disk footprint of the Noto fonts that were required to take macOS to Android/Chrome OS-competitive Unicode coverage was only a couple of megabytes. (The fonts are hidden in /Library/Application Support/Apple/Fonts/Language Support/.) In the case of Ubuntu, the set of Noto fonts required to reach the Chrome OS / Android level of script coverage is a bit larger than in the macOS case but should still be manageable. Please install, by default, those Noto fonts that provide support for scripts that are not properly supported by the fonts that Ubuntu already installs by default. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/fonts-noto/+bug/1866038/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1675024] Re: nouveau fails with orange screen with Quadro M2000 (Maxwell) in 16.04.2
> Have you tried 17.04 if it boots up? Like the report says: "With 17.04 install media, the screen goes black instead of orange." What info should I have included for this not to have been resolved as "Incomplete"? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xserver-xorg-video-nouveau in Ubuntu. https://bugs.launchpad.net/bugs/1675024 Title: nouveau fails with orange screen with Quadro M2000 (Maxwell) in 16.04.2 Status in xserver-xorg-video-nouveau package in Ubuntu: Incomplete Bug description: Steps to reproduce: 1) Use a computer with an Nvidia Quadro M2000 GPU. (I used Lenovo ThinkStation P710 with Lenovo-bundled Quadro M2000.) 2) Boot from Ubuntu 16.04.2 x86_64 live desktop / install USB stick. 3) Choose try Ubuntu before installing from the boot scroon. Actual results: The screen goes orange and then no visible changes take place. Expected results: Expected to start Unity using nouveau-provided OpenGL functionality. Additional info: The 16.04.1 install media results in Unity starting up, but with OpenGL functionality (as reported by Unity and by Firefox) coming from llvmpipe on the CPU and not from nouveau on the GPU. With 17.04 install media, the screen goes black instead of orange. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/1675024/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 228988] Re: Firefox can display a page with the wrong default encoding
Pretty sure this was fixed as upstream bug https://bugzilla.mozilla.org/show_bug.cgi?id=844115 ** Bug watch added: Mozilla Bugzilla #844115 https://bugzilla.mozilla.org/show_bug.cgi?id=844115 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/228988 Title: Firefox can display a page with the wrong default encoding Status in Mozilla Firefox: New Status in Ubuntu: Won't Fix Status in firefox package in Ubuntu: Confirmed Bug description: Since I'm using it, I see Firefox (2.X and 3.X) sometimes display pages using the wrong character encoding. Sometime a page will display correctly, later the same page won't, without any apparent reason why there's a difference. Update: -- Truly, there's something unpredictable in this behaviour of Firefox and of the presented test cases. Hence, I hereby mention a procedure that's reproducible on all my freshly installed systems but unfortunately not on all other ones (mainly US ones) display http://atilf.atilf.fr Click 'Entrez dans le TLF' Fill in search field: 'erreur', click 'Valider 1' Select the word 'ERREUR', a window pops up Click on 'le TLF1' in that window The pop up window invariably displays ISO8859-1 as UTF-8 as shown in http://launchpadlibrarian.net/55706907/Screenshot-Mozilla%20Firefox.png - I have first introduced Bug #206884 but, although it says exactly this, it turns out that several people misunderstood it, that it became a mess and that adding more explanation to it would make the mess even worse. So I'm trying to make it clear and orderly in here, please read more detail in #206884. And, obviously, make #206884 a duplicate of this one, not the opposite. I made tests with http://atilf.atilf.fr/tlf.htm which often displays to me as shown in the attachment. I even found a way to produce a problem. This was Problem #1 and here is the procedure to produce it. 1) clear the said URL from history [any occurrence of the hostname in address bar dropdown] 2) open a new window or tag and do the following in it 3) set View|Character Encoding to UTF-8 (or anything but ISO889-1) 4) type that URL in the address bar and display page 5) the page displays using the wrong encoding (as the attachment, using UTF-8) Repeat 1-5, setting ISO889-1 instead, and you get a correct display. See an alternate procedure and more comments at the end of this text. The obvious problem is that something done before the page displays produces an incorrect character set usage. In this case, we did it willingly but it may be the same problem that occurs unwillingly. Obviously, all pages should contain all the information necessary to display correctly and ONLY AFTER a page was displayed should the user be able to try to display it using other encodings. The header of that page is : Le Trésor de la Langue Française Informatisé We notice that this header doesn't specify the encoding. As far as I know, the default encoding is ISO8858-1. Hence, displaying the page in UTF-8 is always incorrect, unless the user changes the encoding after it was displayed. Additional problem #2 I'll sketch it here. Please also read the bulk in #206884. I was trying to find what could make determining the page encoding uncertain and I found this. 1) Content OptionsPreferences|Fonts & Colors|Character Encoding The character encoding selected here will be used to display pages that do not specify which encoding to use. This preference is unneeded, as, in my mind, the default is always ISO8859-1. Allowing the user to change the default sure is a way to run into problems. The Web will show you people telling others to set it back to ISO8859-1. Yet ... 2) I tried to set this default setting to UTF-8 and, to my amazement, the test URL displayed correctly. 3) It may be that Firefox remembers the pages encodings in history (why I'm asking to clear it). If that's a good feature once the user manually corrects the encoding for a page, it's less appropriate when a user who doesn't know how to change this encoding is hit by this occasional problem as the page encoding will be wrong for history's life instead of occasionally. 4) My discussion about how the standards badly define the encoding and the default encoding is for the Firefox developpers to notify those who write the standards. PS: Having spent hours trying to explain this simple problem and making tests, I just found another way to demonstrate it : 0) Use a freshly started, otherwise empty, Firefox 1) Again, clear the said URL from history [any occurrence of the hostname in address bar dropdown] as if it were the first time you use that URL 2) Use Google to search "Trésor Langue Française Informatisé", check that you get our URL 3) Right-click on link to "Open ... in new Ta
[Desktop-packages] [Bug 1675024] [NEW] nouveau fails with orange screen with Quadro M2000 (Maxwell) in 16.04.2
Public bug reported: Steps to reproduce: 1) Use a computer with an Nvidia Quadro M2000 GPU. (I used Lenovo ThinkStation P710 with Lenovo-bundled Quadro M2000.) 2) Boot from Ubuntu 16.04.2 x86_64 live desktop / install USB stick. 3) Choose try Ubuntu before installing from the boot scroon. Actual results: The screen goes orange and then no visible changes take place. Expected results: Expected to start Unity using nouveau-provided OpenGL functionality. Additional info: The 16.04.1 install media results in Unity starting up, but with OpenGL functionality (as reported by Unity and by Firefox) coming from llvmpipe on the CPU and not from nouveau on the GPU. With 17.04 install media, the screen goes black instead of orange. ** Affects: xserver-xorg-video-nouveau (Ubuntu) Importance: Undecided Status: New ** Summary changed: - nouveau fails with orange screen with Quadro M2000 in 16.04.2 + nouveau fails with orange screen with Quadro M2000 (Maxwell) in 16.04.2 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xserver-xorg-video-nouveau in Ubuntu. https://bugs.launchpad.net/bugs/1675024 Title: nouveau fails with orange screen with Quadro M2000 (Maxwell) in 16.04.2 Status in xserver-xorg-video-nouveau package in Ubuntu: New Bug description: Steps to reproduce: 1) Use a computer with an Nvidia Quadro M2000 GPU. (I used Lenovo ThinkStation P710 with Lenovo-bundled Quadro M2000.) 2) Boot from Ubuntu 16.04.2 x86_64 live desktop / install USB stick. 3) Choose try Ubuntu before installing from the boot scroon. Actual results: The screen goes orange and then no visible changes take place. Expected results: Expected to start Unity using nouveau-provided OpenGL functionality. Additional info: The 16.04.1 install media results in Unity starting up, but with OpenGL functionality (as reported by Unity and by Firefox) coming from llvmpipe on the CPU and not from nouveau on the GPU. With 17.04 install media, the screen goes black instead of orange. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/1675024/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1612928] Re: ARM symbols not available on crash-stats.mozilla.com when Firefox crashes
Wouldn't it make more sense to upload the symbols to let people who care diagnose bugs but not include ARM crashes in Mozilla's crash statistics? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1612928 Title: ARM symbols not available on crash-stats.mozilla.com when Firefox crashes Status in Mozilla Firefox: Confirmed Status in firefox package in Ubuntu: New Bug description: When Firefox crashes on Ubuntu on ARMv7, it offers to report the crash to Mozilla, which is good, but Mozilla's crash reporting system appears to be unable to extract symbols for a stack trace. See e.g. https://crash-stats.mozilla.com/report/index/c6aa6dc1-90f3 -44ec-8f7f-337f72160813 I'm guessing that whatever process is used to upload symbols for Ubuntu's x86/x86_64 builds to Mozilla's server is not being followed for ARMv7. Please make the ARM symbols available to Mozilla for more useful crash reporting. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1612928/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1612928] Re: ARM symbols not available on crash-stats.mozilla.com when Firefox crashes
As a user who might be able to fix the crash, having a crash stack show up without building a debug build myself is more important than on x86_64, because my Raspberry Pi 3 doesn't have enough RAM to link libxul, so just making a debug build on my own and running it under gdb when it crashes doesn't work. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1612928 Title: ARM symbols not available on crash-stats.mozilla.com when Firefox crashes Status in Mozilla Firefox: Confirmed Status in firefox package in Ubuntu: New Bug description: When Firefox crashes on Ubuntu on ARMv7, it offers to report the crash to Mozilla, which is good, but Mozilla's crash reporting system appears to be unable to extract symbols for a stack trace. See e.g. https://crash-stats.mozilla.com/report/index/c6aa6dc1-90f3 -44ec-8f7f-337f72160813 I'm guessing that whatever process is used to upload symbols for Ubuntu's x86/x86_64 builds to Mozilla's server is not being followed for ARMv7. Please make the ARM symbols available to Mozilla for more useful crash reporting. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1612928/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1612928] Re: ARM symbols not available on crash-stats.mozilla.com when Firefox crashes
BMO bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1294952 ** Bug watch added: Mozilla Bugzilla #1294952 https://bugzilla.mozilla.org/show_bug.cgi?id=1294952 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1612928 Title: ARM symbols not available on crash-stats.mozilla.com when Firefox crashes Status in firefox package in Ubuntu: New Bug description: When Firefox crashes on Ubuntu on ARMv7, it offers to report the crash to Mozilla, which is good, but Mozilla's crash reporting system appears to be unable to extract symbols for a stack trace. See e.g. https://crash-stats.mozilla.com/report/index/c6aa6dc1-90f3 -44ec-8f7f-337f72160813 I'm guessing that whatever process is used to upload symbols for Ubuntu's x86/x86_64 builds to Mozilla's server is not being followed for ARMv7. Please make the ARM symbols available to Mozilla for more useful crash reporting. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1612928/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1612928] [NEW] ARM symbols not available on crash-stats.mozilla.com when Firefox crashes
Public bug reported: When Firefox crashes on Ubuntu on ARMv7, it offers to report the crash to Mozilla, which is good, but Mozilla's crash reporting system appears to be unable to extract symbols for a stack trace. See e.g. https://crash-stats.mozilla.com/report/index/c6aa6dc1-90f3 -44ec-8f7f-337f72160813 I'm guessing that whatever process is used to upload symbols for Ubuntu's x86/x86_64 builds to Mozilla's server is not being followed for ARMv7. Please make the ARM symbols available to Mozilla for more useful crash reporting. ** Affects: firefox (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1612928 Title: ARM symbols not available on crash-stats.mozilla.com when Firefox crashes Status in firefox package in Ubuntu: New Bug description: When Firefox crashes on Ubuntu on ARMv7, it offers to report the crash to Mozilla, which is good, but Mozilla's crash reporting system appears to be unable to extract symbols for a stack trace. See e.g. https://crash-stats.mozilla.com/report/index/c6aa6dc1-90f3 -44ec-8f7f-337f72160813 I'm guessing that whatever process is used to upload symbols for Ubuntu's x86/x86_64 builds to Mozilla's server is not being followed for ARMv7. Please make the ARM symbols available to Mozilla for more useful crash reporting. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1612928/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1308395] [NEW] gedit's en-US encoding menu has ISO-8859-15 by default, should have windows-1252
Public bug reported: Steps to reproduce: * Use a fresh en-US install of Ubuntu 14.04 * Open a file that's not valid UTF-8 in gedit Actual results: gedit offers to open the file using a non-UTF-8 encoding. By default, the menu has one non-UTF-8 item: ISO-8859-15. Expected results: Expected the single pre-populated item in the menu to be windows-1252 instead of ISO-8859-15. Additional info: ISO-8859-15 post-dates UTF-8 and is not actually as common a legacy encoding as ISO-8859-1 and windows-1252. windows-1252 is a superset of ISO-8859-1, so there's no point in having ISO-8859-1 in the menu. However, if one is opening legacy files, having windows-1252 in the menu is useful. Putting ISO-8859-15 in the menu instead looks like anti-Microsoft political posturing that's detached from practicality. ** Affects: gedit (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gedit in Ubuntu. https://bugs.launchpad.net/bugs/1308395 Title: gedit's en-US encoding menu has ISO-8859-15 by default, should have windows-1252 Status in “gedit” package in Ubuntu: New Bug description: Steps to reproduce: * Use a fresh en-US install of Ubuntu 14.04 * Open a file that's not valid UTF-8 in gedit Actual results: gedit offers to open the file using a non-UTF-8 encoding. By default, the menu has one non-UTF-8 item: ISO-8859-15. Expected results: Expected the single pre-populated item in the menu to be windows-1252 instead of ISO-8859-15. Additional info: ISO-8859-15 post-dates UTF-8 and is not actually as common a legacy encoding as ISO-8859-1 and windows-1252. windows-1252 is a superset of ISO-8859-1, so there's no point in having ISO-8859-1 in the menu. However, if one is opening legacy files, having windows-1252 in the menu is useful. Putting ISO-8859-15 in the menu instead looks like anti-Microsoft political posturing that's detached from practicality. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/1308395/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1304239] [NEW] Invalidated regions not being consistently repainted on Quadro K600
Public bug reported: Using nouveau as shipped in Ubuntu 14.04 Final Beta 64-bit (both on the live installation media and on the actual instealled system) with Nvidia Quadro K600, invalidated regions are not consistently repainted. For example, the mouse cursor can leave a trail for a moment or background color changes in Firefox don't show until e.g. the mouse cursor moving over the area forces an update. ii libdrm-nouveau2:amd64 2.4.52-1 amd64Userspace interface to nouveau-specific kernel DRM services -- runtime ii xserver-xorg-video-nouveau1:1.0.10-1ubuntu2 amd64X.Org X server -- Nouveau display driver ** Affects: xserver-xorg-video-nouveau (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xserver-xorg-video-nouveau in Ubuntu. https://bugs.launchpad.net/bugs/1304239 Title: Invalidated regions not being consistently repainted on Quadro K600 Status in “xserver-xorg-video-nouveau” package in Ubuntu: New Bug description: Using nouveau as shipped in Ubuntu 14.04 Final Beta 64-bit (both on the live installation media and on the actual instealled system) with Nvidia Quadro K600, invalidated regions are not consistently repainted. For example, the mouse cursor can leave a trail for a moment or background color changes in Firefox don't show until e.g. the mouse cursor moving over the area forces an update. ii libdrm-nouveau2:amd64 2.4.52-1 amd64Userspace interface to nouveau-specific kernel DRM services -- runtime ii xserver-xorg-video-nouveau1:1.0.10-1ubuntu2 amd64X.Org X server -- Nouveau display driver To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/1304239/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 206884]
(In reply to Launchpad from comment #19) > André Pirard added the following comment to Launchpad bug report 206884: > > How would you make the menu "say" this? > Language to [auto]detect encoding for > Language to suit [auto-detection] > ... something like that That's unusually wordy for a submenu label. :-( > Please note that "Universal" is not a language and that I still do not > understand what that means. The people who understood what it *really* meant can probably be counted with the fingers of one hand. That's one of the reasons why I removed that item from the menu. > Also, (Off) could be "no encoding auto-detection" to make it very clear > what we're about. I wouldn't be opposed to re-labeling "(Off)" to something like "No Detection". -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/206884 Title: fuzzy/confusing firefox View -> Character encoding menu semantics Status in The Mozilla Firefox Browser: Fix Released Status in The Great Mass of Obsolete Junk: Won't Fix Status in “firefox” package in Ubuntu: Triaged Bug description: Please note that I am not the reporter of this bug any longer. Alexander Sack is. He changed the title to his own understanding. I personnally understand View -> Character encoding perfectly. What I say is that FF does not always display ISO8859-1 by default. André. I have seen this since long with both Firefox 2.x and 3.0b3. Rem: Please note that I don't say that Firefox always uses the wrong encoding. Please read my followup to see how to reproduce the problem. I display, for example, http://atilf.atilf.fr/tlf.htm Its header is Le Trésor de la Langue Française Informatisé Hence, its encoding should be ISO8859-1 by default as it has always been. As the uploaded attachment shows Firefox displays it using UTF-8. In Edit|Preferences|Content|Font & Colors|Default font|Advanced|Character Encoding there's an option named "Default character encoding" documented as follows The character encoding selected here will be used to display pages that do not specify which encoding to use. What's the use of this setting if the default must ALWAYS be ISO8859-1? Otherwise said, what would be the definition of a changing default? It can only cause people to _produce_ the error I describe. Hence, produce confusion. I saw people say that the wrong behavior I describe is caused by a wrong setting. There should obviously be no user setting for a necessary default. How could the heck a user know what default to set in his browser before being able to read a page if the only place it can be said is in that page he could only read by setting the correct default ;-) And this option was left to ISO8859-1 in my browser, of course. Search www.w3.org/TR/html401/charset.html for "default" and you will learn that a HTML document character code that should obviously be specified within the document is designed to be specified in the HTTP header (without saying BTW how it is specified when FTP is used) with ISO8859-1 as the default. Note that this blunder attributed to HTTP servers accused of not being able to detect the character code of files they store or of being misconfigured has been circumvented by introducing a META directive able to provide -- from the HTML document itself -- HTTP header data and hence the character code. But note that this is done without concluding that ISO8859-1 is the default code of META too, and hence of the document, without regard to the following question. Question : how the heck could a HTML "user agent" that ignores the default character set work any better than my posting this if you and I didn't know that we have to use ASCII? Answer : no better than the page display I show in my attachment. And finally, note that if the reliability of the expected result of a standard lies in this phrase : "By combining these mechanisms, an author can greatly improve the chances that, when the user retrieves a resource, the user agent will recognize the character encoding." the conclusion is : "OK, OK, that was only my bad luck again, it's a random game, bug dismissed, Firefox within said specs, I have to try again". Or should we try to see why Firefox didn't display ISO8859-1? I've see browsers do that for years. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/206884/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 206884]
(In reply to André Pirard from comment #17) > I think that the first thing for Character Encoding Autodetect to be less > confusing is ti say what it does. > Assuming that it means that any indication of a character set is ignored ans > that it is guessed by the contents... It means: If the type of the document is text/html or text/plain and there is no character encoding label on the HTTP layer or inside the document (in the text/html case) and there is no BOM at the start of the document, assume the language of the page is the one selected from the Auto-Detect menu and make a guess based on the contents of the file given that language assumption. How would you make the menu "say" this? Note: My current belief is that we don't actually need the Russian and Ukrainian autodetectors. Once the only autodetector we have is the Japanese one, we should probably not bother the user about its existence but couple it with choosing Japanese in Preferences: Content: Advanced: Fallback Character Encoding [or choosing "Default for Current Locale" in the Japanese localization]. Therefore, I think activity to get rid of the Russian and Ukrainian detectors (bug 845791) would be more productive than activity to polish the menu. > Character Encoding Autodetect is normally not needed because a page MUST > specify the encoding it uses. Correct. > Using it instead of reporting an error to a webmaster is causing the > webmaster to continue to make the same errors. Indeed. > Also, picking the character code from the HTTP request is an error because > the contents of the page MUST specify the encoding, it knows better than an > Apache server Indeed, Ruby's Postulate generally holds. Unfortunately, HTTP disagreed and it's too late to change that, because it would break pages that currently work due to Ruby's Postulate not being true for them. http://www.intertwingly.net/slides/2004/devcon/69.html And besides, all browser now agree on the precedence of HTTP over , so it's not worthwhile to break interoperability. > and the browser won't update the page when it's written to a > file. Firefox is supposed to if you choose the "complete" option in Save As... > The only case where character encoding mangling is necessary is when, for > example, displaying a text file of which the character set is specified > nowhere Or when displaying an HTML file whose character encoding is specified nowhere. :-( -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/206884 Title: fuzzy/confusing firefox View -> Character encoding menu semantics Status in The Mozilla Firefox Browser: Fix Released Status in The Great Mass of Obsolete Junk: Won't Fix Status in “firefox” package in Ubuntu: Triaged Bug description: Please note that I am not the reporter of this bug any longer. Alexander Sack is. He changed the title to his own understanding. I personnally understand View -> Character encoding perfectly. What I say is that FF does not always display ISO8859-1 by default. André. I have seen this since long with both Firefox 2.x and 3.0b3. Rem: Please note that I don't say that Firefox always uses the wrong encoding. Please read my followup to see how to reproduce the problem. I display, for example, http://atilf.atilf.fr/tlf.htm Its header is Le Trésor de la Langue Française Informatisé Hence, its encoding should be ISO8859-1 by default as it has always been. As the uploaded attachment shows Firefox displays it using UTF-8. In Edit|Preferences|Content|Font & Colors|Default font|Advanced|Character Encoding there's an option named "Default character encoding" documented as follows The character encoding selected here will be used to display pages that do not specify which encoding to use. What's the use of this setting if the default must ALWAYS be ISO8859-1? Otherwise said, what would be the definition of a changing default? It can only cause people to _produce_ the error I describe. Hence, produce confusion. I saw people say that the wrong behavior I describe is caused by a wrong setting. There should obviously be no user setting for a necessary default. How could the heck a user know what default to set in his browser before being able to read a page if the only place it can be said is in that page he could only read by setting the correct default ;-) And this option was left to ISO8859-1 in my browser, of course. Search www.w3.org/TR/html401/charset.html for "default" and you will learn that a HTML document character code that should obviously be specified within the document is designed to be specified in the HTTP header (without saying BTW how it is specified when FTP is used) with ISO8859-1 as the default. Note that this blunder attributed to HTTP servers accused of not being able to detect the character code of files th
[Desktop-packages] [Bug 206884]
Bug 805374 made both the Auto-Detect submenu and the Character Encoding menu in general less confusing. I think we should either consider the menu adequately non-confusing as of Firefox 28 and mark this FIXED or concede that it's not going to become less confusing until/unless we get rid of the menu eventually some day: i.e. WONTFIX. (I think we have a pretty good chance of getting rid of the remaining Russian and Ukrainian options and then coupling Japanese autodetection with Shift_JIS fallback and getting rid of autodetection UI.) Trying the FIXED interpretation. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/206884 Title: fuzzy/confusing firefox View -> Character encoding menu semantics Status in The Mozilla Firefox Browser: Fix Released Status in The Great Mass of Obsolete Junk: Won't Fix Status in “firefox” package in Ubuntu: Triaged Bug description: Please note that I am not the reporter of this bug any longer. Alexander Sack is. He changed the title to his own understanding. I personnally understand View -> Character encoding perfectly. What I say is that FF does not always display ISO8859-1 by default. André. I have seen this since long with both Firefox 2.x and 3.0b3. Rem: Please note that I don't say that Firefox always uses the wrong encoding. Please read my followup to see how to reproduce the problem. I display, for example, http://atilf.atilf.fr/tlf.htm Its header is Le Trésor de la Langue Française Informatisé Hence, its encoding should be ISO8859-1 by default as it has always been. As the uploaded attachment shows Firefox displays it using UTF-8. In Edit|Preferences|Content|Font & Colors|Default font|Advanced|Character Encoding there's an option named "Default character encoding" documented as follows The character encoding selected here will be used to display pages that do not specify which encoding to use. What's the use of this setting if the default must ALWAYS be ISO8859-1? Otherwise said, what would be the definition of a changing default? It can only cause people to _produce_ the error I describe. Hence, produce confusion. I saw people say that the wrong behavior I describe is caused by a wrong setting. There should obviously be no user setting for a necessary default. How could the heck a user know what default to set in his browser before being able to read a page if the only place it can be said is in that page he could only read by setting the correct default ;-) And this option was left to ISO8859-1 in my browser, of course. Search www.w3.org/TR/html401/charset.html for "default" and you will learn that a HTML document character code that should obviously be specified within the document is designed to be specified in the HTTP header (without saying BTW how it is specified when FTP is used) with ISO8859-1 as the default. Note that this blunder attributed to HTTP servers accused of not being able to detect the character code of files they store or of being misconfigured has been circumvented by introducing a META directive able to provide -- from the HTML document itself -- HTTP header data and hence the character code. But note that this is done without concluding that ISO8859-1 is the default code of META too, and hence of the document, without regard to the following question. Question : how the heck could a HTML "user agent" that ignores the default character set work any better than my posting this if you and I didn't know that we have to use ASCII? Answer : no better than the page display I show in my attachment. And finally, note that if the reliability of the expected result of a standard lies in this phrase : "By combining these mechanisms, an author can greatly improve the chances that, when the user retrieves a resource, the user agent will recognize the character encoding." the conclusion is : "OK, OK, that was only my bad luck again, it's a random game, bug dismissed, Firefox within said specs, I have to try again". Or should we try to see why Firefox didn't display ISO8859-1? I've see browsers do that for years. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/206884/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1051559]
(In reply to Fabio from comment #22) > Maybe it was already discussed, but Mozilla was not interested in supporting > only free codecs? Why the change to support also (software that can enable > play of) patented codecs? https://brendaneich.com/2012/03/video-mobile-and-the-open-web/ -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1051559 Title: Build Firefox with GStreamer support Status in The Mozilla Firefox Browser: Confirmed Status in “firefox” package in Ubuntu: Triaged Bug description: Building Firefox with GStreamer support would provide support for a lot of websites that use h264. To build Firefox with GStreamer support you should use the "--enable-gstreamer" option. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1051559/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1051559]
(In reply to Ralph Giles (:rillian) from comment #18) > Perhaps we should add some infrastructure to let us blacklist particular > gstreamer elements, the way we do with plugins? I think it’s more important to make really, really sure that the only GStreamer things that are whitelisted are: * MP4 demuxer * H.264 decoder * (LC-)AAC decoder * MP3 decoder only in the context of .mp3 container I’d leave Firefox agnostic to which specific implementations of these live on the other side of GStreamer. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1051559 Title: Build Firefox with GStreamer support Status in The Mozilla Firefox Browser: Confirmed Status in “firefox” package in Ubuntu: Triaged Bug description: Building Firefox with GStreamer support would provide support for a lot of websites that use h264. To build Firefox with GStreamer support you should use the "--enable-gstreamer" option. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1051559/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1051559]
(In reply to Ralph Giles (:rillian) from comment #14) > Keep in mind that calling system gstreamer libraries means feeding data from > the network into code we have no way to issue security fixes for. We are already on track to doing that on Android, and the Android security update situation is worse than the security update situation on various desktop Linux distros. As in: It’s worse to the point of not having system updates—security or other—in most cases. (In reply to sam tygier from comment #15) > some related discussion in the distros, > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682917 > https://bugzilla.redhat.com/show_bug.cgi?id=843583 I think it would be unwise for distros to turn GStreamer on before bug 760140 is fixed. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1051559 Title: Build Firefox with GStreamer support Status in The Mozilla Firefox Browser: Confirmed Status in “firefox” package in Ubuntu: Triaged Bug description: Building Firefox with GStreamer support would provide support for a lot of websites that use h264. To build Firefox with GStreamer support you should use the "--enable-gstreamer" option. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1051559/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 782970] Re: LibreOffice should provide high-resolution icons to the alt-tab window switcher
Seems solved in 11.10. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libreoffice in Ubuntu. https://bugs.launchpad.net/bugs/782970 Title: LibreOffice should provide high-resolution icons to the alt-tab window switcher Status in “libreoffice” package in Ubuntu: Confirmed Bug description: Binary package hint: libreoffice Steps to reproduce: 1) Have Unity running 2) Click the Firefox high-res icon that is in the Unity Launcher by default 3) Click the LibreOffice Calc high-res icon that is in the Unity Launcher by default 4) Wait for Firefox and LibreOffice Calc to launch 5) Hold down the alt key and press the tab key Actual result: A low-resolution OpenOffice-esque icon is shown in the window switcher for the LibreOffice Calc window. The icon is different from the one shown in the Unity Launcher. In contrast, the Firefox window is associated with a shiny high-resolution icon. Expected results: Expected to see the same high-resolution icon for LibreOffice Calc in the the windows switcher as in the Unity Launcher. ProblemType: Bug DistroRelease: Ubuntu 11.04 Package: libreoffice (not installed) ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2 Uname: Linux 2.6.38-8-generic x86_64 NonfreeKernelModules: nvidia Architecture: amd64 Date: Sun May 15 14:12:33 2011 EcryptfsInUse: Yes InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027) ProcEnviron: LANGUAGE=en_US:en LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: libreoffice UpgradeStatus: Upgraded to natty on 2011-05-14 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/782970/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 874023] Re: Low-resolution icon in the app switcher
-- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gucharmap in Ubuntu. https://bugs.launchpad.net/bugs/874023 Title: Low-resolution icon in the app switcher Status in “gucharmap” package in Ubuntu: New Bug description: Steps to reproduce: 1) Launch Gnome Terminal 2) Launch Firefox 3) Launch Character Map 4) Press alt-tab Actual results: The icon for Character Map shown in the app switcher has a low resolution which makes it look ugly and out of place compared to the terminal and Firefox icons. Expected results: Expected to see a high-resolution icon for Character Map in the app switcher. ProblemType: Bug DistroRelease: Ubuntu 11.10 Package: gucharmap 1:3.2.0-0ubuntu1 ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4 Uname: Linux 3.0.0-12-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 1.23-0ubuntu3 Architecture: amd64 Date: Fri Oct 14 12:50:32 2011 EcryptfsInUse: Yes ExecutablePath: /usr/bin/gucharmap InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027) ProcEnviron: PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: gucharmap UpgradeStatus: Upgraded to oneiric on 2011-10-14 (0 days ago) XsessionErrors: (nautilus:2117): Gtk-CRITICAL **: gtk_action_set_visible: assertion `GTK_IS_ACTION (action)' failed (nautilus:2117): Gtk-CRITICAL **: gtk_action_set_visible: assertion `GTK_IS_ACTION (action)' failed (Do:2132): Wnck-CRITICAL **: wnck_set_client_type got called multiple times. (gnome-settings-daemon:2090): Gdk-WARNING **: The program 'gnome-settings-daemon' received an X Window System error. (gedit:2502): Gtk-CRITICAL **: gtk_list_store_set_column_types: assertion `priv->columns_dirty == 0' failed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gucharmap/+bug/874023/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 874023] [NEW] Low-resolution icon in the app switcher
Public bug reported: Steps to reproduce: 1) Launch Gnome Terminal 2) Launch Firefox 3) Launch Character Map 4) Press alt-tab Actual results: The icon for Character Map shown in the app switcher has a low resolution which makes it look ugly and out of place compared to the terminal and Firefox icons. Expected results: Expected to see a high-resolution icon for Character Map in the app switcher. ProblemType: Bug DistroRelease: Ubuntu 11.10 Package: gucharmap 1:3.2.0-0ubuntu1 ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4 Uname: Linux 3.0.0-12-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 1.23-0ubuntu3 Architecture: amd64 Date: Fri Oct 14 12:50:32 2011 EcryptfsInUse: Yes ExecutablePath: /usr/bin/gucharmap InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027) ProcEnviron: PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: gucharmap UpgradeStatus: Upgraded to oneiric on 2011-10-14 (0 days ago) XsessionErrors: (nautilus:2117): Gtk-CRITICAL **: gtk_action_set_visible: assertion `GTK_IS_ACTION (action)' failed (nautilus:2117): Gtk-CRITICAL **: gtk_action_set_visible: assertion `GTK_IS_ACTION (action)' failed (Do:2132): Wnck-CRITICAL **: wnck_set_client_type got called multiple times. (gnome-settings-daemon:2090): Gdk-WARNING **: The program 'gnome-settings-daemon' received an X Window System error. (gedit:2502): Gtk-CRITICAL **: gtk_list_store_set_column_types: assertion `priv->columns_dirty == 0' failed ** Affects: gucharmap (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug apport-lpi oneiric running-unity -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gucharmap in Ubuntu. https://bugs.launchpad.net/bugs/874023 Title: Low-resolution icon in the app switcher Status in “gucharmap” package in Ubuntu: New Bug description: Steps to reproduce: 1) Launch Gnome Terminal 2) Launch Firefox 3) Launch Character Map 4) Press alt-tab Actual results: The icon for Character Map shown in the app switcher has a low resolution which makes it look ugly and out of place compared to the terminal and Firefox icons. Expected results: Expected to see a high-resolution icon for Character Map in the app switcher. ProblemType: Bug DistroRelease: Ubuntu 11.10 Package: gucharmap 1:3.2.0-0ubuntu1 ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4 Uname: Linux 3.0.0-12-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 1.23-0ubuntu3 Architecture: amd64 Date: Fri Oct 14 12:50:32 2011 EcryptfsInUse: Yes ExecutablePath: /usr/bin/gucharmap InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027) ProcEnviron: PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: gucharmap UpgradeStatus: Upgraded to oneiric on 2011-10-14 (0 days ago) XsessionErrors: (nautilus:2117): Gtk-CRITICAL **: gtk_action_set_visible: assertion `GTK_IS_ACTION (action)' failed (nautilus:2117): Gtk-CRITICAL **: gtk_action_set_visible: assertion `GTK_IS_ACTION (action)' failed (Do:2132): Wnck-CRITICAL **: wnck_set_client_type got called multiple times. (gnome-settings-daemon:2090): Gdk-WARNING **: The program 'gnome-settings-daemon' received an X Window System error. (gedit:2502): Gtk-CRITICAL **: gtk_list_store_set_column_types: assertion `priv->columns_dirty == 0' failed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gucharmap/+bug/874023/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
