[Bug 1476705] Re: postscript printer hideously slow in some cases (pdftops)
Bruno, To be honest, I don't know what differs between the two tools, as they both come from Cairo, I assumed that pdftops was just a small wrapper around the same code as pdftocairo but with the options pre-set for PS output. I'm a Ghostscript developer, so I can't really answer specifics about Cairo - I know about the problems with the Cairo PDF output, as we've performance problems in Ghostscript with those, and have had some fairly lengthy (and heated) discussions with Cairo developers on the subject. And I have helped debug a lot of these problems with the Ghostscript output, so I can give general suggestions as I did above. If I had to guess, I would say that pdftocairo is possibly spotting that the PDF originated as a Cairo file, and is using inside knowledge of how those are constructed to convert it back into Cairo internal representation, which is then outputs to Postscript - with that level of extra information, it can probably be much, much smarter about when there is real transparency that it has to render, and when everything opaque, and remain in high level form. Whilst, pstops may be doing a simpler, one step PDF to Postscript conversion. Ideally, what you'd want to try is (if possible) to keep the ProRes (I thought it was ImageRET) mode, but still tell pdftocairo to use 600 dpi, as you then may get the benefits of more the accurate dot placement, better halftone results, and possibly better color management, whilst keeping the quicker processing of the smaller image data. It's hard to know without deep inside knowledge, but (again) if I had to guess, I would suggest that the slightly lower quality halftone screen is what's causing the slight intensity shift you mention. HP are pretty tight lipped about these technologies, but I know other such systems tend to allow the halftoning to represent more shades of the color, without losing detail (generally there is a trade off: you can approximate lots of shades, but lose detail, or have great detail, but very few shades). Chris -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to poppler in Ubuntu. https://bugs.launchpad.net/bugs/1476705 Title: postscript printer hideously slow in some cases (pdftops) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/1476705/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1476705] Re: postscript printer hideously slow in some cases (pdftops)
pdftops and pdftocairo are both from poppler. pdftops is based on the original xpdf code and does not use cairo at all. modern cairo tries to limit the size of tranparency groups to just where it is needed. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to poppler in Ubuntu. https://bugs.launchpad.net/bugs/1476705 Title: postscript printer hideously slow in some cases (pdftops) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/1476705/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1477251] [NEW] st_segment_to_stream_time: assertion 'segment-format == format' failed
Public bug reported: My Rhythmbox (3.1-1ubuntu3) is crashing very often. The last few times I opened it from command line instead of via menu and got this error: GStreamer-CRITICAL **: gst_segment_to_stream_time: assertion 'segment-format == format' failed Twice it happened when Rhythmbox was about to start playing a next MP3, but the third time I started the MP3 that it crashed on before and now it is playing. Other crashes seem pretty random. Don't hav any info or log from those. Unless there is some log where Rhythmbox automatically writes crash reports? I'm using Ubuntu 15.04, kernel 3.19.0-22-generic. ** Affects: rhythmbox (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to rhythmbox in Ubuntu. https://bugs.launchpad.net/bugs/1477251 Title: st_segment_to_stream_time: assertion 'segment-format == format' failed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/1477251/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 797485] Re: Status Bar Covers File Name at Bottom
Indeed *extremely* annoying - at renaming a file and other occasions. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/797485 Title: Status Bar Covers File Name at Bottom To manage notifications about this bug go to: https://bugs.launchpad.net/nautilus/+bug/797485/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1476705] Re: postscript printer hideously slow in some cases (pdftops)
The problem, I suspect, is the way Cairo rights PDF files (the gmap.pdf file you attached above was created by Cairo). The Cairo *always* writes the page contents into one or more PDF transparency groups - even when all the contents are really opaque. The issue is that, due to the way PDF works (and PDF transparency in particular) the only way to be sure that all the page contents are opaque would be to pre-process each page, checking for non-opaque content, and then re-interpret the page using the information gleaned in the first pass - which would, frankly, result in an unacceptable performance drop for the vast majority of PDF files. Most interpreters I know will pre-scan the quickly accessible elements of a PDF page, and if no transparency constructs are found, will then elide the extra processing transparency requires. Unfortunately, those easily accessible elements don't contain (or, at least, don't reliably contain) the actual opacity information. So, in most cases I know, just the existence of the transparency constructs means that extra processing is enabled, regardless of the actual opacity values. Now, secondly, Postscript cannot represent PDF transparency in high level (vector etc) operations. So, the only way to get a visually accurate representation of a PDF containing transparency in Postscript is to flatten the transparency by rendering it to a sampled image - and clearly, sampled images end up being larger than vector graphics. Hence we have the result that basically every Cairo produced PDF will convert to Postscript as one or more sampled images per page. And that explains why the Postscript is so much larger than the PDF. Now, looking at the Postscript file you posted, it *appears* that the rendering for transparency flattening is being done at 1200dpi which is, frankly, ridiculous for a couple of reasons. First is, your printer has a maximum physical resolution of 600dpi (the ImageRET modes provide enhanced quality, claimed to be equivalent to 2400 and, IIRC, 3600 dpi, but the printer is still a 600 dpi printer). Secondly, our experience with Ghostscript's Postscript output, is that many printers are much, *much* faster at upsampling images than downsampling. So, my first suggestion would be to poke around the CUPS dialogues and/or the PPD, and see if you can drop the claimed resolution of the printer to at most 600dpi and, frankly, I'd even try 300 dpi. As a rule of thumb, in the printing world, it's generally claimed that dropping continuous tone, sampled image resolution by 50% from the physical resolution results in almost no visible loss of quality. Where that falls down, in cases like this, is because there is text involved, and the small details inherent in text shapes may well suffer visibly. Another thing we've found with the Postscript output from Ghostscript is that many printers are very, very slow at decompressing data, so if you can find an option to avoid compressing image data, that *might* make a difference - but that is highly printer dependent. I'd like to take this opportunity to rant (again): this kind of thing is the reason that PDF is such poor, poor choice as a print spool format. PDF has a *hugely* rich imaging model, *far* more so than Postscript, PCL5/PXL or any of the proprietary page description languages (PDL), which means for almost any low/midrange PDL based printer, there is a very high chance that the PDF content cannot be converted to a high level, vector representation, and must be rendered and sent as sampled images (bitmaps). Perhaps a PDF/A or PDF/X variant would be a better choice.. And I'm sure someone will point out that more and more printers are supporting direct PDF printing, but that really just moves the bottleneck: PDF transparency is (over!) complex, and is extremely processor and memory intensive. So a low/mid range printer, with limited memory and processing power, is going to struggle to print a file like these ones. In truth, many such PDF printers get around this by either not supporting transparency at all, or supporting only relatively trivial subset of the full PDF transparency model. Also, with more and more applications integrating Cairo to do their PDF output, with the transparency problems outlined above, the situation is only set to get worse. /rant Anyway, as I said, look into adjusting the resolution, and possibly compression settings, and let us know how you fare. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to poppler in Ubuntu. https://bugs.launchpad.net/bugs/1476705 Title: postscript printer hideously slow in some cases (pdftops) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/1476705/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1414930] Re: [Lenovo ThinkPad 2015 models] Buttons of Synaptics trackpad doesn't work
** Changed in: hwe-next Status: In Progress = Fix Released -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1414930 Title: [Lenovo ThinkPad 2015 models] Buttons of Synaptics trackpad doesn't work To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1414930/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1410765] Re: GIMP uses more system resources than necessary
** Changed in: gimp Status: Incomplete = Expired -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gimp in Ubuntu. https://bugs.launchpad.net/bugs/1410765 Title: GIMP uses more system resources than necessary To manage notifications about this bug go to: https://bugs.launchpad.net/gimp/+bug/1410765/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1468199] Re: package gconf2 3.2.6-3ubuntu1 failed to install/upgrade: 子进程 已安装 post-installation 脚本 返回错误状态 1
This happens if /usr/bin/python points to a Python 3 interpreter. The gconf2 python scripts at /usr/sbin/gconf-schemas and /usr/bin /update-gconf-defaults expect a python2 environment. One way to fix it in live is to edit those files and change the first line to #!/usr/bin/python2 -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gconf in Ubuntu. https://bugs.launchpad.net/bugs/1468199 Title: package gconf2 3.2.6-3ubuntu1 failed to install/upgrade: 子进程 已安装 post- installation 脚本 返回错误状态 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gconf/+bug/1468199/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1477106] [NEW] Cups directive Browsing Off ignored by print dialog
Public bug reported: On Ubuntu 15.04, I have cups configured with the Browsing Off option in the /etc/cups/cupsd.conf to disallow listing non local printers (I'm on a huge network where there are many printers). This works well with non Gnome applications (LibreOffice, Adobe Reader for example). But the print dialog of Gnome GTK3 applications seems to ignore the Browsing Off directive and lists a lot of remote printers... The same problem arises with Gnome GTK2 applications... cups version: 2.0.2-1ubuntu3.2 gtk3 version: 3.14.13-0ubuntu1 gtk2 version: 2.24.27-0ubuntu1 The package cups-browsed is not installed. Here is the content of my cupsd.conf: # # Configuration file for the CUPS scheduler. See man cupsd.conf for a # complete description of this file. # # Log general information in error_log - change warn to debug # for troubleshooting... LogLevel warn PageLogFormat # Deactivate CUPS' internal logrotating, as we provide a better one, especially # LogLevel debug2 gets usable now MaxLogSize 0 # Only listen for connections from the local machine. Listen localhost:631 Listen /var/run/cups/cups.sock # Show shared printers on the local network. Browsing Off BrowseLocalProtocols dnssd # Default authentication type, when authentication is required... DefaultAuthType Basic # Web interface setting... WebInterface Yes # Restrict access to the server... Location / Order allow,deny /Location # Restrict access to the admin pages... Location /admin Order allow,deny /Location # Restrict access to configuration files... Location /admin/conf AuthType Default Require user @SYSTEM Order allow,deny /Location # Set the default printer/job policies... Policy default # Job/subscription privacy... JobPrivateAccess default JobPrivateValues default SubscriptionPrivateAccess default SubscriptionPrivateValues default # Job-related operations must be done by the owner or an administrator... Limit Create-Job Print-Job Print-URI Validate-Job Order deny,allow /Limit Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job Cancel-My-Jobs Close-Job CUPS-Move-Job CUPS-Get-Document Require user @OWNER @SYSTEM Order deny,allow /Limit # All administration operations require an administrator to authenticate... Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default CUPS-Get-Devices AuthType Default Require user @SYSTEM Order deny,allow /Limit # All printer operations require a printer operator to authenticate... Limit Pause-Printer Resume-Printer Enable-Printer Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer Startup-Printer Promote-Job Schedule-Job-After Cancel-Jobs CUPS-Accept-Jobs CUPS-Reject-Jobs AuthType Default Require user @SYSTEM Order deny,allow /Limit # Only the owner or an administrator can cancel or authenticate a job... Limit Cancel-Job CUPS-Authenticate-Job Require user @OWNER @SYSTEM Order deny,allow /Limit Limit All Order deny,allow /Limit /Policy # Set the authenticated printer/job policies... Policy authenticated # Job/subscription privacy... JobPrivateAccess default JobPrivateValues default SubscriptionPrivateAccess default SubscriptionPrivateValues default # Job-related operations must be done by the owner or an administrator... Limit Create-Job Print-Job Print-URI Validate-Job AuthType Default Order deny,allow /Limit Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job Cancel-My-Jobs Close-Job CUPS-Move-Job CUPS-Get-Document AuthType Default Require user @OWNER @SYSTEM Order deny,allow /Limit # All administration operations require an administrator to authenticate... Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default AuthType Default Require user @SYSTEM Order deny,allow /Limit # All printer operations require a printer operator to authenticate... Limit Pause-Printer Resume-Printer Enable-Printer Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer Startup-Printer Promote-Job Schedule-Job-After Cancel-Jobs CUPS-Accept-Jobs CUPS-Reject-Jobs AuthType Default Require user @SYSTEM Order deny,allow /Limit # Only the owner or an administrator can cancel or authenticate a job... Limit Cancel-Job CUPS-Authenticate-Job AuthType Default
[Bug 1477322] [NEW] Select-by-typing select hidden files even if they are not shown
Public bug reported: I was going to report this upstream, but then I remembered that type- ahead selection of files was removed by retarted upstream Nautilus maintainers, and it has been patched back by Ubuntu as per https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1164016 So: Steps to reproduce: 1) Have a folder with these files: aaa.txt aaa.txt~ (hidden) aab.txt~ (hidden) aac.txt 2) Open the folder in Nautilus; make sure that the show hidden files option is NOT enabled = so you only see aaa.txt and aac.txt 3) Type: aa 4) Hit the down arrow key several times. Expected behavior: * Since hidden files are not being shown, they should not be selectable by type-ahead. Hence, - after typing aa, aaa.txt should be selected - at the first keystroke on the down arrow, aac.txt should be selected Observed behavior: - After typing aa, aaa.txt is selected, as expected - At the first keystroke on the down arrow, no file seems to be selected. aaa.txt is no longer highlighted but aac.txt isn't either. Under the hood, I guess the aaa.txt~ file is somehow selected (but if you hit Enter nothing happens, thank god) - At the second keystroke, still nothing seems to change: still no file apparently selected. But under the hood, aab.txt~ is probably somehow selected - At the third keystroke, finally aac.txt is selected, proving that Nautilus is somehow selecting files even if they are hidden. Behaving like a file is selected (in that the previous selected one is unselected and that you can skip to the next one) while it is not even visible is INCONSISTENT. The most reasonable expected behavior is to select and loop through only visible files, so, if hidden files aren't being shown, only non-hidden files must be considered, while if hidden files are being shown, then they must be considered. Another sensible behavior could be to make the hidden files that match the typed string become visible, and highlight them when they are selected, but that would eventually lead to counterintuitive behavior and design issues (what do you do when the type-ahead box disappear? turn back the hidden files to invisible?) == ANOTHER EXAMPLE == Say you have, in a folder: aaa.txt~ (hidden) aab.txt You type aa Expected: aab.txt should be highlighted and selected Observed: nothing is highlighted, which is exactly the same that would happen if no file matching the typed string existed. So you may even think the file doesn't exist (if you don't look carefully enough, which usually you don't want to, because that is why you use type-ahead in the first place), or you see it right in front of your eyes and you say why the heck isn't it found??. Only if you think about using the arrow keys you will realize that the file you're looking for actually exists. Which means that TYPE-AHEAD IS BASICALLY UNRELIABLE: you type something, you see nothing selected, and that's no guarantee that no matching file exists, until you use up/down arrow keys. (actually, you will never be sure: what if there were hundreds of hidden files starting with the typed string? Unlikely but possible) The whole design of the type-ahead find thingie (which is a very useful, vital feature) is actually shitty. It lacks at least one of two things: either 1) showing the number of matches found or 2) changing the color of the typed text or its background when no match is found ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: nautilus 1:3.10.1-0ubuntu9.7 ProcVersionSignature: Ubuntu 3.13.0-55.94-generic 3.13.11-ckt20 Uname: Linux 3.13.0-55-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.11 Architecture: amd64 CurrentDesktop: Unity Date: Wed Jul 22 23:29:18 2015 GsettingsChanges: b'org.gnome.nautilus.list-view' b'use-tree-view' b'true' b'org.gnome.nautilus.list-view' b'default-column-order' b['name', 'size', 'type', 'date_modified', 'date_accessed', 'owner', 'group', 'permissions', 'mime_type', 'where'] InstallationDate: Installed on 2013-10-11 (649 days ago) InstallationMedia: Ubuntu 13.04 Raring Ringtail - Release amd64 (20130424) SourcePackage: nautilus UpgradeStatus: Upgraded to trusty on 2014-05-24 (424 days ago) ** Affects: nautilus (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug trusty ** Description changed: I was going to report this upstream, but then I remembered that type- ahead selection of files was removed by retarted upstream Nautilus maintainers, and it has been patched back by Ubuntu as per https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1164016 So: Steps to reproduce: 1) Have a folder with these files: - aaa.txt - aaa.txt~ (hidden) - aab.txt~ (hidden) - aac.txt + aaa.txt + aaa.txt~ (hidden) + aab.txt~ (hidden) + aac.txt 2) Open the folder in Nautilus; make sure that the show hidden files option is NOT enabled - = so you only see aaa.txt and aac.txt + = so you only see aaa.txt and aac.txt 3) Type: aa 4) Hit the
[Bug 1477322] Re: Select-by-typing select hidden files even if they are not shown
Please for god's sake don't underestimate the importance of this bug. I would hate to see this rated as low or even medium. Please read the second use case example carefully. This fulfills at least the criteria for high: - has a severe* impact on a small portion of Ubuntu users (estimated) Checking for existence of a file and getting a false negative is definitely a severe impact - Has a moderate impact on a large portion of Ubuntu users (estimated) I think users who use type-ahead at all are a large portion (large enough that Ubuntu decided to reintroduce a feature that had been retardedly removed upstream), and the impact is at least moderate in common use cases And probably: - Renders essential features or functionality of the application or dependencies broken or ineffective It might be questioned whether type-ahead is an essential feature of Nautilus, but the bug definitely renders it broken *and* ineffective. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1477322 Title: Select-by-typing select hidden files even if they are not shown To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1477322/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1476705] Re: postscript printer hideously slow in some cases (pdftops)
@cliddell Wow, thank you for all these informations. As I said before, my first sample (gmap.pdf) prints quickly now with pdftocairo. For this document, it seems that few extra processing is done. However, the second sample (see appout of my printer test page, also created by Cairo) was still slow to print, even with pdftocairo (with much extra processing, as you describe). If I choose (as you suggested) 600 dpi instead ProRes 1200, this sheet is printed in less than a minute. It's not quick but acceptable now for my home need. I see some differences on the intensity of the logo and dashed lines, but overall the quality appears to be good enough. So I now set this printer in 600 dpi by default. I continue to observe that pdftocairo is quicker (big difference for gmap.pdf), so I conserve this setting also. Is there any drawback to this? If not, why not set pdftocairo as the default renderer, for postscript printers? -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to poppler in Ubuntu. https://bugs.launchpad.net/bugs/1476705 Title: postscript printer hideously slow in some cases (pdftops) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/1476705/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1477182] [NEW] Transparency failing gnome-terminal
Public bug reported: After recently changing from Ubuntu 15.04 with Unity, to Ubuntu Gnome 15.04, I have noticed that in Ubuntu Gnome, if I go into the profile settings and enable Transparency for gnome-terminal, it will only take effect once I have resized the gnome-terminal window by the means of pulling the window to another side of my screen and make it snap to a certain size (so if I pull it to the top it will maximize, if to the side, it will only then take up half of the screen). I have also noticed that if I open any other gnome-terminal window that I must go into the settings, and change the settings slightly for the Transparency (turning it off and on again, or moving the slider), even though the settings show it to be on, then I must get it to do the resize by dragging it to one edge of my screen (as I mentioned earlier) for the gnome-terminal to be transparent, otherwise it stays whatever colour I have set it to. --- OS Information: No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 15.04 Release:15.04 Codename: vivid Package Information: gnome-terminal: Installed: 3.14.2-0ubuntu3 Candidate: 3.14.2-0ubuntu3 Version table: *** 3.14.2-0ubuntu3 0 500 http://gb.archive.ubuntu.com/ubuntu/ vivid/main amd64 Packages 100 /var/lib/dpkg/status ** Affects: ubuntu-gnome Importance: Undecided Status: New ** Affects: gnome-terminal (Ubuntu) Importance: Undecided Status: New ** Also affects: gnome-terminal (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1477182 Title: Transparency failing gnome-terminal To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-gnome/+bug/1477182/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
