[Desktop-packages] [Bug 1697772] [NEW] dont know
Public bug reported: not working proply ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: xorg 1:7.7+13ubuntu3 ProcVersionSignature: Ubuntu 4.8.0-36.36~16.04.1-generic 4.8.11 Uname: Linux 4.8.0-36-generic x86_64 .tmp.unity_support_test.0: ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 BootLog: [[0;32m OK [0m] Started LSB: Speech Dispatcher. CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: compiz CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0' CompositorUnredirectFSW: true Date: Wed Jun 14 01:59:55 2017 DistUpgraded: Fresh install DistroCodename: xenial DistroVariant: ubuntu GraphicsCard: NVIDIA Corporation G98M [GeForce G 103M] [10de:06ef] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company G98M [GeForce G 103M] [103c:306a] InstallationDate: Installed on 2017-06-13 (0 days ago) InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.2) MachineType: Hewlett-Packard Compaq Presario CQ61 Notebook PC ProcEnviron: LANGUAGE=en_IN:en PATH=(custom, no user) LANG=en_IN SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.8.0-36-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7 SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/13/2009 dmi.bios.vendor: Hewlett-Packard dmi.bios.version: F.20 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: 306A dmi.board.vendor: Hewlett-Packard dmi.board.version: 21.14 dmi.chassis.type: 10 dmi.chassis.vendor: Hewlett-Packard dmi.chassis.version: N/A dmi.modalias: dmi:bvnHewlett-Packard:bvrF.20:bd10/13/2009:svnHewlett-Packard:pnCompaqPresarioCQ61NotebookPC:pvrRev1:rvnHewlett-Packard:rn306A:rvr21.14:cvnHewlett-Packard:ct10:cvrN/A: dmi.product.name: Compaq Presario CQ61 Notebook PC dmi.product.version: Rev 1 dmi.sys.vendor: Hewlett-Packard version.compiz: compiz 1:0.9.12.2+16.04.20160823-0ubuntu1 version.ia32-libs: ia32-libs N/A version.libdrm2: libdrm2 2.4.70-1~ubuntu16.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 12.0.6-0ubuntu0.16.04.1 version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A version.libgl1-mesa-glx: libgl1-mesa-glx 12.0.6-0ubuntu0.16.04.1 version.xserver-xorg-core: xserver-xorg-core N/A version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A xserver.bootTime: Wed Jun 14 01:15:01 2017 xserver.configfile: default xserver.errors: Failed to load module "nvidia" (module does not exist, 0) Failed to load module "nvidia" (module does not exist, 0) xserver.logfile: /var/log/Xorg.0.log xserver.version: 2:1.18.4-1ubuntu6.1~16.04.1 xserver.video_driver: nouveau ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug compiz-0.9 ubuntu xenial -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1697772 Title: dont know Status in xorg package in Ubuntu: New Bug description: not working proply ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: xorg 1:7.7+13ubuntu3 ProcVersionSignature: Ubuntu 4.8.0-36.36~16.04.1-generic 4.8.11 Uname: Linux 4.8.0-36-generic x86_64 .tmp.unity_support_test.0: ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 BootLog: [[0;32m OK [0m] Started LSB: Speech Dispatcher. CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: compiz CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0' CompositorUnredirectFSW: true Date: Wed Jun 14 01:59:55 2017 DistUpgraded: Fresh install DistroCodename: xenial DistroVariant: ubuntu GraphicsCard: NVIDIA Corporation G98M [GeForce G 103M] [10de:06ef] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company G98M [GeForce G 103M] [103c:306a] InstallationDate: Installed on 2017-06-13 (0 days ago) InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.2) MachineType: Hewlett-Packard Compaq Presario CQ61 Notebook PC ProcEnviron: LANGUAGE=en_IN:en PATH=(custom, no user) LANG=en_IN SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.8.0-36-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7 SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/13/2009 dmi.bios.vendor: Hewlett-Packard dmi.bios.version: F.20 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: 306A dmi.board.vendor: Hewlett-Packard dmi.board.version: 21.14 dmi.chassis.type: 10 dmi.chassis.vendor: Hewlett-Packard dmi.chassis.version: N/A dmi.modalias: dmi:bvnHewlett-Packard:bvrF.20:bd10/13
[Desktop-packages] [Bug 206884]
(In reply to Masatoshi Kimura [:emk] from comment #14) > No, no, not at all. "Universal" is going to be killed. > I think this bug is obsolete due to recent massive changes to Character > Encoding menu. In that case, I am letting someone else take over this :) -- 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: Confirmed 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]
Hi Athira, You need to change "(off)" in [1] to "Universal". To see the change, you could just build toolkit/locales/ with `mach build toolkit/locales/` and `mach run` to see the changes. Good Luck! [1]: http://mxr.mozilla.org/mozilla-central/source/toolkit/locales/en- US/chrome/global/charsetMenu.dtd#10 -- 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: Confirmed 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
