You are here

Agreguesi i feed

Matthias Clasen: More text rendering updates

Planet GNOME - Sht, 27/07/2019 - 11:06md

There is a Pango 1.44 release now. It contains all the changes I outlined recently. We also managed to sneak in a few features and fixes for longstanding bugs. That is the topic of this post.

Line breaking

One area for improvements in this release is line breaking.


We don’t have TeX-style automatic hyphenation yet (although it may happen eventually). But at least, Pango inserts hyphens now when it breaks a line in the middle of a word (for example, at a soft hyphen character).

Example with soft hyphens

This is something i have wanted to do for a very long time, so I am quite happy that switching to harfbuzz for shaping on all platforms has finally enabled us to do this without too much effort.

Better line breaks

Pango follows Unicode UAX14 and UAX29 for finding word boundaries and line break opportunities.  The algorithm described in there is language-independent, but allows for language-specific tweaks. The Unicode standard calls this tailoring.

While Pango has had implementations for both the language-independent and -dependent parts before, we didn’t have them clearly separated in the API, until now.

In 1.44, we introduce a new pango_tailor_break() function which applies language-specific tweaks to a segment of text that has a uniform language. It is meant to be called after pango_default_break().

Line break control

Since my focus was on line-breaking already, I’ve added support for a text attribute to control line breaking. You can now say:

Don't break <span allow_break="false">here!</span>

in Pango markup, and Pango will obey.

In the hyphenation example above, the words showing possible hyphenation points (like im‧peachment) are marked up in this way.


Another area with significant changes is placement, both of lines and of individual glyphs.

Line height

Up to now, Pango has been placing the lines of a paragraph directly below each other, possibly with a fixed amount of spacing between them. While this works ok most of the time, a more typographically correct way to go about this is to control the baseline-to-baseline distance between lines.

Fonts contain a recommended value for this distance, so the first step was to make this value available with a new pango_font_metrics_get_height() API.

To make use of it, we added a new parameter to PangoLayout that tells it to place lines according to baseline-to-baseline distance. Once we had this, it was very easy to turn the parameter into a floating point number and allow things like double-spaced lines, by saying

pango_layout_set_line_spacing (layout, 2.0) Line spacing 1, 1.5, and 2

You can still use the old way of spacing if you set line-spacing to 0.

Subpixel positions

Pango no longer rounds glyph positions and font metrics to integral pixel numbers. This lets consumers of the formatted glyphs (basically, implementations of PangoRenderer) decide for themselves if they want to place glyphs at subpixel positions or pixel-aligned.

Non-integral extents

The cairo renderer in libpangocairo will do subpixel positioning, but you need cairo master for best results. GTK master will soon have the necessary changes to take advantage of it for its GL and Vulkan renderers too.

This is likely one of the more controversial changes in this release—any change to font rendering causes strong reactions. One of the reasons for doing the release now is that it gives us enough time to make sure it works ok for all users of Pango before going out in the next round of upstream and distro releases in the fall.


Finally, I spent some time implementing  some long-requested features around missing glyphs, and their rendering as hex boxes. These are also known as tofu (which is the origin of the name for the Noto fonts – ‘no tofu’).

Invisible space

Some fonts don’t have a glyph for the space character – after all, there is nothing to draw. In the past, Pango would sometimes draw a hex box in this case. This is entirely unnecessary – we can just leave a gap of the right size and pretend that nothing happened.  Pango 1.44 will do just that: no more hex boxes for space.

Visible space

On the other hand, sometimes you do want to see where spaces and other whitespace characters such as tabs, are. We’ve added an attribute that lets you request visible rendering of whitespace:

<span show="spaces">Some space here</span> Visible space

This is implemented in the cairo backend, so you will need to use pangocairo to see it.

Special characters

In the same vein, sometimes it is helpful to see special characters such as left-to-right controls in the output.  Unicode calls these characters default-ignorable.

The show attribute also lets you make default-ignorables visible:

<span show=”ignorables”>Hidden treasures</span>

Visible default-ignorable characters

As you can see, we use nicknames for ignorables.

Font information

Pango has been shipping a simple tool called pango-list for a while. It produces a list of all the fonts Pango can find.  This can be very helpful in tracking down changes between systems that are caused by differences in the available fonts.

In 1.44, pango-list can optionally show font metrics and variation axes as well. This may be a little obsure, but it has helped me fix the CI tests for Pango.


This release contains a significant amount of change; I’ve closed a good number of ‘teenage’ bugs while working on it. Please let us know if you see problems or unexpected changes with it!

Sebastian Pölsterl: scikit-survival 0.9 released

Planet GNOME - Sht, 27/07/2019 - 9:36md

This release of scikit-survival adds support for scikit-learn 0.21 and pandas 0.24, among a couple of other smaller fixes. Please see the release notes for a full list of changes. If you are using scikit-survival in your research, you can now cite it using an Digital Object Identifier (DOI).

Hans Petter Jansson: desktop-file-utils 0.24 released

Planet GNOME - Pre, 26/07/2019 - 2:06pd

One thing one can do in this amazing summer heat, is cut the 0.24 release of desktop-file-utils. It’s rather a small thing, but since the last few releases have been happening at roughly three-year intervals I felt it merited a quick post.

Changes since 0.23 desktop-file-validate
  • Allow desktop file spec version 1.2 (Severin Glöckner).
  • Add Budgie, Deepin, Enlightenment and Pantheon to list of registered desktop environments (fdo#10, fdo#11, fdo#16, oldfdo#97385) (Ikey Doherty, sensor.wen, Joonas Niilola, David Faure).
  • Sort output lines internally to conserve reproducibility (fdo#12) (Chris Lamb).
  • Use pledge(2) on OpenBSD to limit capabilities (fdo#13) (Jasper Lievisse Adriaanse).
  • Fix missing ; when appending to a list not ending with one (oldfdo#97388) (Pascal Terjan).
  • Add font as valid media type (Matthias Clasen).
  • Fix broken emacs blocking compile (fdo#15) (Hans Petter Jansson, reported by John).

desktop-file-utils contains command line utilities for working with desktop entries:

  • desktop-file-validate: Validates a desktop file according to the desktop entry specification.
  • desktop-file-install: Installs a desktop file to the applications directory after applying optional modifications.
  • update-desktop-database: Updates the database containing a cache of MIME types handled by desktop files.

Thanks to everyone who contributed to this release! And an extra big thanks to Daniel Stone for his patient support.

Michael Hill: Documentation at the West Coast Hackfest

Planet GNOME - Enj, 25/07/2019 - 5:52md

The West Coast Hackfest was a terrific experience. The venue, the Urban Office coworking space, was ideal. Sharing the space, and the energy, with the Engagement and GTK teams was inspirational. Thanks in particular to Britt for his thoughtful presentation on growing the team.

The workspace at Urban Office.

Thursday, the first day, we had a brainstorming session. We triaged and then started attacking the GitLab issues for gnome-user-docs. Over the hackfest, we reduced 28 outstanding issues to 12.5. This entailed 33 commits and 105+ user help pages modified (in addition to a few pages in the Sys Admin Guide, and the wiki).

My part consisted of Bluetooth and Wacom pages, touchscreen gestures (still in progress, the 0.5 of an issue), general Settings updates, and some of the terminology fixes.

Nifty Control Panel feature — like others, the Wacom panel is hidden if no device is connected. This would seem to defeat the help instructions. However, when you search and select the panel from the activities overview, Settings opens to the Wacom panel and its hidden message of No stylus found/No tablet detected.

Hard at work on docs.

Friday evening we worked late in the coffee shop of Powell’s City of Books, with (a hint of) free wifi, easily accessible hot chocolate and cookies, and acres of reference material.

On Saturday, we discussed the logistics of replacing library-web with Pintail for User Docs, and Petr and Jim started implementing it.

Pioneer Courthouse Square.

Saturday evening was the fun all-team event. We experienced the Portland Night Market, a combination craft fair and rib fest in the space between the off-ramps in the Industrial District.

Three-team event on Saturday night (photo courtesy of Christian Hergert).

Portland is a good place for a hackfest. The transit system is excellent, and there is a nicely photogenic mountain just over 80 km away. Thank you to the organizers for a tremendous event, and thanks to the GNOME Foundation for sponsoring my travel and accommodation.

Mount Hood looming over the Skyline. Unlike the postcard version, you have to zoom in.

Federico Mena-Quintero: Constructors

Planet GNOME - Mër, 24/07/2019 - 8:59md

Have you ever had these annoyances with GObject-style constructors?

  • From a constructor, calling a method on a partially-constructed object is dangerous.

  • A constructor needs to set up "not quite initialized" values in the instance struct until a construct-time property is set.

  • You actually need to override GObjectClass::constructed (or was it ::constructor?) to take care of construct-only properties which need to be considered together, not individually.

  • Constructors can't report an error, unless you derive from GInitable, which is not in gobject, but in gio instead. (Also, why does that force the constructor to take a GCancellable...?)

  • You need more than one constructor, but that needs to be done with helper functions.

This article, Perils of Constructors, explains all of these problems very well. It is not centered on GObject, but rather on constructors in object-oriented languages in general.

(Spoiler: Rust does not have constructors or partially-initialized structs, so these problems don't really exist there.)

(Addendum: that makes it somewhat awkward to convert GObject code in C to Rust, but librsvg was able to solve it nicely with <buzzword>the typestate pattern</buzzword>.)

Srestha Srivastava

Planet GNOME - Mër, 24/07/2019 - 8:23md
  GSoC 2019: New Learnings1. Virtual methods can be overridden in derived classes, while abstract methods must be overridden.  

2. A class that has atleast one abstract method must be an abstract class.  

3. We can't create instances of abstract classes.

4. GObject subclasses are any classes derived directly or indirectly from GLib.Object. They support a lot of features like signals, managed properties, interfaces and complex construction methods.(reference).

About git
  • Soft reset: this feature allows to remove the commits but keeps the changes made in files saved whereas hard reset removes the saved changes from file also.
  • When we create a merge request by comparing two branches, the commits included in the MR get updated every time we update either of the branch, if we update the branch that we used to compare our new branch, the new commits included in that branch will not be included in the MR.

    Jim Campbell: West Coast Docs Hackfest - 2019

    Planet GNOME - Mër, 24/07/2019 - 8:22md

    This past week I joined several other members of the GNOME docs team (as well as the Engagement and GTK teams) to work as part of the West Coast Hackfest in Portland, Oregon. From the GNOME Docs side, our efforts were split between resolving documentation issue reports, improving our CI, and making some initial steps towards better help on the web.

    On the issues side, we resolved over 20 doc issues, many of which involved multiple components and discussions to arrive at the best way to fix the problem. For myself, I revamped the instructions on how to search from within the GNOME Files / Nautilus application, which mainly involved updating the current help and adding information on how you can customize which directories are included (or not included) in the search results. As part of this, I also filed a bug to improve a UI component of the search customization. I was able to give a bit of love to gedit docs, as well, though there is still more to do to bring those docs fully up-to-date.

    For CI, Dave King integrated some yelp-check validation tests into our CI process. Because these tests run quickly, we moved them close to the start of the CI process so that the tests will fail early-on if there are syntax issues in the documentation.

    A good chunk of our efforts on the latter days were spent on an update to, which we're initially targeting for the 3.36 release. The update involves a transition from 'Library Web' to 'Pintail' as our site building tool. This will allow for easier site maintenance by a broader group of contributors, which will make everyone in the whole world very happy. There's a good chunk of back-end tooling that needs to be in place before we stand anything up, so we don't have any user-facing drafts for people to see, but it was well-worth our time to start on this with so many of us in the room.

    Although we'd like to do more with transitioning from Mallard XML to Ducktype, our primary focus over the next releases is going to be on making sure documentation stays up-to-date and that we improve the web help situation. Getting the latter component in place is critical to making our documentation easier to maintain in the future.

    As a side note, I'm fortunate that my employer fully funded my attendance at the hackfest, and is supportive of my contributions to GNOME.

    Jim Campbell: Ubuntu documentation at UDS: A summary

    Planet GNOME - Mër, 24/07/2019 - 8:22md

    Now that my week at the Ubuntu Developer Summit is over, and I have completed my safe flight back, I thought I would write up a blog post about my experience while I complete my recovery from jet lag.

    My week at UDS was a challenging week. A great week. A week in which I had great discussions around docs, met lots of cool people, and wound up expanding the limits of what are normally considered acceptable sleep patterns.

    I had three docs-team sessions during the week. I also attended two sessions about cloud-related documentation, and another session on server documentation. The three docs-team sessions focused on the team strategy, our goals for the 11.10 release cycle, and evaluating a web-based documentation platform.

    Team Strategy

    The inspiration for the team strategy discussion is the Xubuntu Strategy Document. Have you read it? When Cody Somerville first wrote it, part of me was like, "Are you serious? Did you write this yourself?" It seemed too complicated. In practice, though, I've seen the Xubuntu team reference that document while making decisions time and time again. I think a similar document would benefit the docs team, too. I'm preparing a draft document based off of recent team discussions, and will be sharing it in the next week.

    Team Goals for the 11.10 Release

    The team goals session was pretty great. People in the room, and people listening in via the audio casts, gave helpful input. There was more focus on the Ubuntu wiki at UDS than I anticipated. Some of our goals for this cycle include creating a strategy document, contributing to upstream docs projects, refactoring our team wiki, testing of documentation accessibility, testing a preferred help layout, doing stable release updates for docs and translations, squashing boogs, adopting a consistent coding style, updating our style guide (or picking an existing one), and doing some of the initial work in revamping

    It sounds like a lot, and it is, but some of it is already a work in progress. We will make these goals explicit during our next team meeting.

    Web-based Documentation Platform

    The group behind this project is Pronovix, a Drupal consultancy. I knew that their project was using Drupal and DITA, but I wasn't sure what *their project did*. They had some of their staff based in Hungary, just a short trip away from Budapest, so I thought it was worth getting in touch to learn more about their approach and how it might benefit us.

    DITA stands for the Darwin Information Typing Architecture, an XML syntax developed by IBM that specializes in content profiling and content reuse. The advantage of content reuse with a tool like DITA is that it allows you to write something once, write it well, and reuse it most everywhere. That is the idea, at least. Implementation of DITA can be difficult. Their project has promise, but the toolchain isn't currently packaged by any distro other than OpenSUSE. Harald Sitter (Mr. Apache Log File) felt that this very much limits the likelihood of upstream adoption.

    Even with that in mind, we are going to seriously evaluate their platform. It was very considerate of this group to make a trip to demonstrate their project, and we want to be supportive of everyone who is working in open source documentation.

    There are quite a few irons in our fire, and we'll have to get word out about our activities somehow. Our progress will likely be presented via a new Ubuntu Documentation Team blog. We think now is a good time to start one up, so look for more info on that soon, as well.


    Subscribe to AlbLinux agreguesi