Bug#1051831: ITP: python-ntc-templates -- TextFSM Templates for Network Devices, and wrapper for TextFSM's CliTable
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-ntc-templates Version : 3.5.0 Upstream Contact: Network to Code * URL : https://github.com/networktocode/ntc-templates/ * License : Apache-2.0 Programming Lang: Python Description : TextFSM Templates for Network Devices, and wrapper for TextFSM's CliTable This package contains TextFSM Templates for Network Devices, and a Python wrapper for TextFSM's CliTable. TextFSM helps make parsing cli commands more manageable. Note: this is a new dependency of netmiko that I would like to upgrade to the latest upstream release. Netmiko, itself, is a dependency of OpenStack networking-generic-switch, that configures vendor specific stuff of switches, so that Ironic (OpenStack baremetal) can work and setup things like VLANs automatically.
Bug#1051838: ITP: python-scrapli-replay -- enable easy testing of scrapli programs
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-scrapli-replay Version : 2023.7.30 Upstream Contact: Carl Montanari * URL : https://github.com/scrapli/scrapli_replay * License : Expat Programming Lang: Python Description : enable easy testing of scrapli programs Easily test scrapli code with Pytest, or create mock SSH servers to play with. . Within Debian, this package is only useful for running unit tests for the package python-scrapli. Note: this is an indirect dependency for netmiko
Re: What licenses should be included in /usr/share/common-licenses?
On Sat, 2023-09-09 at 20:35 -0700, Russ Allbery wrote: > Licenses will be included in common-licenses if they meet all of the > following criteria: > > * The license is DFSG-free. > * Exactly the same license wording is used by all works covered by it. > * The license applies to at least 100 source packages in Debian. > * The license text is longer than 25 lines. That is a good starting point. The third rules could be made more relaxed to also allow including licences that will save disk space for common installations (todo: define what is common). Example: More than 2 (or 3) source packages use this license which produce binary packages that are part of the desktop and/or server seed. -- Benjamin Drung Debian & Ubuntu Developer
Re: Default font: Transition from DejaVu to Noto
On 2023-09-12 03:09, Jonas Smedegaard wrote:
Quoting Gioele Barabucci (2023-09-12 09:19:26)
On 12/09/23 08:24, Fabian Greffrath wrote:
Instead, even
the fonts-noto-core package installs a full pack of 268 (!) font files.
This is discussed in detail in #983291 [1].
The issues is not that there are too many files, but that these files
become extra entries in font pickers (1 entry for every ~3 files).
Why not collapse all these font files into a few new font files using
fontforge or a variant of nototools's merge_fonts.py?
For example Noto Serif {Ahom, Bengali, Devanagari, Malayalam, Tamil,
Thai, …} could be merged into "Noto Serif Asia". Then, Noto * {Africa,
America, Asia, Europe, Oceania, Symbols} could be shipped in the
fonts-noto-aggregated package and their entries added to Debian's
fontconfig as default fallbacks. This would greatly alleviate the
problem of having too many entries in the font pickers, yet provide the
same coverage of fonts-noto-core.
Please discuss that proposal with the Noto project upstream, not here.
My understanding (and I believe documented somewhere too, e.g. in the
Noto CJK subproject which is the most extreme in amount of glyphs) is
that it is technically impossible to join all glyphs due to limitations
of the font formats.
Indeed, font have a 64K limit on the number of glyphs. There is a
proposal[1] to increase this limit, and it is being discussed [2].
Merging some (so not all, so the 64K limit is not reached) of the Noto
fonts together might work. In addition to merging the sets of glyphs,
you would also need to merge the OpenType layout data in the GSUB and
GPOS tables.
And the tool[3] from Google looks like it might handle the GSUB/GPOS
merging.
Different fonts (say for Devanagari and Arabic) might have different
line spacing, a merged font would have to choose which line spacing to
use. As a result, the line spacing in the font might be too loose, or it
might be too tight, resulting in clipping and/or inter-line clashes
depending on which script was being displayed. The source for the tool
mentions this line spacing issue.
And yes, Noto provides separate fonts for (in this example) Arabic and
Devanaragi) even though the top of the Noto website[4] says "Noto: A
typeface for the world" (sort of implying one font) but further down the
page it says "Noto is a collection of high-quality fonts" (plural)
I am curious about the comment above "1 entry for every ~3 files" In
LibreOffice Writer (7.5.6) on my Ubuntu (22.04) system at least,
installing a variable font results in fewer lines in a font picker that
installing a bunch of static fonts.
[1]
https://github.com/harfbuzz/boring-expansion-spec/blob/main/beyond-64k.md
[2] https://github.com/harfbuzz/boring-expansion-spec/issues/105
[3]
https://github.com/notofonts/nototools/blob/main/nototools/merge_fonts.py
[4] https://fonts.google.com/noto
--
Bobby de Vos
/bobby_de...@sil.org/
Re: Default font: Transition from DejaVu to Noto
On 2023-09-12 05:40, Adam Borowski wrote: You don't need to physically merge font files, fontconfig is fine with many fonts sharing the same name. You can't then request a specific font, but taking missing glyphs from others still works. (Haven't looked at this in a while, would need to test.) I am curious if this method would cause ligatures (which are essential in many non-roman scripts) to still form. For the ligatures to display, the OpenType shaping engine needs to see a run of text (all the codepoints that make up a ligature) with a specific font that has the needed GSUB rules. If the missing glyphs are taken one by one, I would have thought that ligature formation would then be broken. -- Bobby de Vos /bobby_de...@sil.org/
Re: Default font: Transition from DejaVu to Noto
Quoting Bobby de Vos (2023-09-13 18:47:22)
> On 2023-09-12 03:09, Jonas Smedegaard wrote:
> > Quoting Gioele Barabucci (2023-09-12 09:19:26)
> >> On 12/09/23 08:24, Fabian Greffrath wrote:
> >>> Instead, even
> >>> the fonts-noto-core package installs a full pack of 268 (!) font files.
> >>> This is discussed in detail in #983291 [1].
> >>
> >> The issues is not that there are too many files, but that these files
> >> become extra entries in font pickers (1 entry for every ~3 files).
> >>
> >> Why not collapse all these font files into a few new font files using
> >> fontforge or a variant of nototools's merge_fonts.py?
> >>
> >> For example Noto Serif {Ahom, Bengali, Devanagari, Malayalam, Tamil,
> >> Thai, …} could be merged into "Noto Serif Asia". Then, Noto * {Africa,
> >> America, Asia, Europe, Oceania, Symbols} could be shipped in the
> >> fonts-noto-aggregated package and their entries added to Debian's
> >> fontconfig as default fallbacks. This would greatly alleviate the
> >> problem of having too many entries in the font pickers, yet provide the
> >> same coverage of fonts-noto-core.
> >
> > Please discuss that proposal with the Noto project upstream, not here.
> >
> > My understanding (and I believe documented somewhere too, e.g. in the
> > Noto CJK subproject which is the most extreme in amount of glyphs) is
> > that it is technically impossible to join all glyphs due to limitations
> > of the font formats.
>
> Indeed, font have a 64K limit on the number of glyphs. There is a
> proposal[1] to increase this limit, and it is being discussed [2].
>
> Merging some (so not all, so the 64K limit is not reached) of the Noto
> fonts together might work. In addition to merging the sets of glyphs,
> you would also need to merge the OpenType layout data in the GSUB and
> GPOS tables.
>
> And the tool[3] from Google looks like it might handle the GSUB/GPOS
> merging.
>
> Different fonts (say for Devanagari and Arabic) might have different
> line spacing, a merged font would have to choose which line spacing to
> use. As a result, the line spacing in the font might be too loose, or it
> might be too tight, resulting in clipping and/or inter-line clashes
> depending on which script was being displayed. The source for the tool
> mentions this line spacing issue.
>
> And yes, Noto provides separate fonts for (in this example) Arabic and
> Devanaragi) even though the top of the Noto website[4] says "Noto: A
> typeface for the world" (sort of implying one font) but further down the
> page it says "Noto is a collection of high-quality fonts" (plural)
>
> I am curious about the comment above "1 entry for every ~3 files" In
> LibreOffice Writer (7.5.6) on my Ubuntu (22.04) system at least,
> installing a variable font results in fewer lines in a font picker that
> installing a bunch of static fonts.
Thanks for those details, Bobby.
Let me however reiterate my main point of previous post, which still
stands:
Please discuss that proposal with the Noto project upstream, not here.
Kind regards,
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Re: Default font: Transition from DejaVu to Noto
On 2023-09-09 23:08, Gunnar Hjalmarsson wrote: My personal view is that it is a change in the right direction, It struck me that I stated a position in my initial post without really arguing for it. Silly me. So with this message I try to repair that, and also highlight the questions I think this topic really boils down to. There are at least two questions: 1. Should fonts-noto-core be installed by default? 2. Which font should fontconfig prefer? At this moment, i.e. if you install Debian via a trixie ISO, the situation is: * fonts-noto-core gets installed by default. How? Because it's first in this list: $ apt-cache depends fontconfig-config | grep fonts |Depends: fonts-noto-core |Depends: fonts-dejavu-core |Depends: fonts-liberation |Depends: fonts-croscore |Depends: fonts-freefont-otf |Depends: fonts-freefont-ttf |Depends: fonts-urw-base35 Depends: fonts-texgyre * fontconfig prefers Noto for sans-serif and serif, while it prefers DejaVu for monospace. Hence the current defaults for latin scripts are: sans-serif Noto Sans serifNoto Serif monospaceDejaVu Sans Mono (or Noto Mono if fonts-dejavu-mono is not installed) Note that that differs from Debian 12. In Debian 12 with GNOME, for instance, fonts-noto-core is not installed by default, but fonts-noto-mono is (because of a long chain of "Recommends:"). At the same time fontconfig prefers Noto also for monospace, which lead to these defaults: sans-serif DejaVu Sans serifDejaVu Serif monospaceNoto Sans Mono I think that is the situation which lead to some reactions in bug reports in the beginning of the year. Several users expressed their dissatisfaction with the switch from DejaVu Sans Mono to Noto Sans Mono. And in response to that the default monospace font has been changed back to DejaVu Sans Mono in trixie. But let us discuss the two questions above. Should fonts-noto-core be installed by default? --- Personally I think it should. The primary reason is that fonts-noto-core offers a broad coverage of Unicode characters, and the quality is in many cases superior to the free alternatives. Ask for instance an Arabic or Sinhala speaking user. To really make use of a Noto font, the font configuration may need to be tweaked. But having it installed is the basic prerequisite, and I think it makes sense that Debian as an internationally spread OS provides fonts of good quality for most languages. There is a problem with fonts-noto-core, though, as several people have mentioned already: For non-LCG scripts it provides one font per script. And there are quite a few of those. So for a user, who wants to actively and often select font in a font picker, the list of font options gets horribly long. Personally I see that as a shortcoming in the font pickers. They ought to offer some "favorites" functionality, in the same manner as it works with keyboard layouts. Unfortunately they don't, at least as far as I know. So we have a conflict of goals here. The good news is that a user who speaks some latin language, and who thinks it's important to be able to easily select font directly in various applications, can do: apt purge fonts-noto-core But the many fonts is not only a disadvantage. It allows you to prefer Noto fonts for some non-latin scripts, and other fonts for other ditto. This flexibility is effectively blocked if DejaVu Sans, where everything is bundled into the same font, is installed and default. Which font should fontconfig prefer? Since it already has been changed back to DejaVu Sans Mono for monospace, let's talk about sans-serif/serif here. Which font looks best? Noto, DejaVu, or something else? Apparently it's primarily a matter of personal preferences. Personally I'm not very sensitive, and I find several available fonts acceptable. Things which speak for Noto is that it's being maintained upstream, it's preferred by fontconfig upstream, and several other distros have choosen Noto. One thing I would like to say here is that when comparing different fonts, you need to be attentive to the font rendering settings. As an example I think that enabling 10-sub-pixel-rgb.conf is a good idea for many screens when using Noto fonts. -- Rgds, Gunnar Hjalmarsson
Re: Default font: Transition from DejaVu to Noto
Hi Fabian, On 2023-09-12 08:24, Fabian Greffrath wrote: as has already been stated elsewhere, fontconfig upstream's move to Noto as the default font has most probably not been done for aesthetical reasons. That is, it is not the "most beautiful font" that people "like better" then DejaVu, but the single usable fallback font with the widest glyph coverage. That might be true. However, I think that the acceptance - or rather lack thereof - of the Noto fonts in Debian has indeed to do with the way they are currently packaged. There is no pendant to the fonts-dejavu-core package which only installs the generic serif and sans-serif flavors. Instead, even the fonts-noto-core package installs a full pack of 268 (!) font files. This is discussed in detail in #983291 [1]. The way they are packaged is absolutely a restriction. How important restriction it is depends on what you want to achieve. If I recall it correctly, the primary suggestion in that bug report is to split fonts-noto-core into an LCG and an "other" package. If that would happen, you would be able to install Noto for LCG scripts only (only a handful fonts, even if you include things like math and symbols). I'm sure that some people consider that to be sufficient. They don't see it as an issue if "tofus"[2] show up once in a while, since they don't understand those characters anyway. Personally I dislike "tofus". They give me a feeling that my system is broken, even if I still wouldn't understand the beautiful characters that are not rendered properly. Maybe I'm colored from having used Ubuntu for more than a decade. The Ubuntu desktop has for a long time installed fonts packages which cover a lot of Asian etc. languages. By default. For everyone. So the ongoing switch to Noto is not such a big deal on Ubuntu. fonts-noto-core gets installed by default, and quite a few font packages for non-latin scripts are dropped. Some people have complained.[3] But overall I think that most users like the idea with a worldwide font coverage. I realize that Debian has done it differently, and for that reason installing fonts-noto-core in Debian — whether as default or fallback — is a bigger change. But if we would want to enter 'the worldwide coverage path', splitting up fonts-noto-core wouldn't make much of a difference, would it? So, if asked for my personal opinion, I could live with DejaVu Mono as the default monospace font (for aesthetical reasons) and Noto Sans and Serif as the default sans-serif and serif fonts (for pragmatic reasons), respectively, but only if the latter are packaged separately. So you see that as a condition.. Please consider what I wrote above. Also, I realized that I failed to really argue for my position when starting this thread, so I have posted another long message in an attempt to structure the discussion: https://lists.debian.org/debian-devel/2023/09/msg00146.html Cheers, - Fabian [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983291 [2] https://fonts.google.com/knowledge/glossary/tofu [3] https://discourse.ubuntu.com/t/20924 -- Rgds, Gunnar
Re: Default font: Transition from DejaVu to Noto
Quoting Gunnar Hjalmarsson (2023-09-13 21:09:00) > Should fonts-noto-core be installed by default? > --- > Personally I think it should. The primary reason is that fonts-noto-core > offers a broad coverage of Unicode characters, and the quality is in > many cases superior to the free alternatives. Ask for instance an Arabic > or Sinhala speaking user. > > To really make use of a Noto font, the font configuration may need to be > tweaked. But having it installed is the basic prerequisite, and I think > it makes sense that Debian as an internationally spread OS provides > fonts of good quality for most languages. > > There is a problem with fonts-noto-core, though, as several people have > mentioned already: For non-LCG scripts it provides one font per script. > And there are quite a few of those. So for a user, who wants to actively > and often select font in a font picker, the list of font options gets > horribly long. > > Personally I see that as a shortcoming in the font pickers. They ought > to offer some "favorites" functionality, in the same manner as it works > with keyboard layouts. Unfortunately they don't, at least as far as I know. Perhaps it is then immature to switch to using fonts-noto by default, for the above reason alone (but see also further comments below). > So we have a conflict of goals here. The good news is that a user who > speaks some latin language, and who thinks it's important to be able to > easily select font directly in various applications, can do: > > apt purge fonts-noto-core Just as easily as those disliking a font can remove it, those appreciating a font can install it. Difference is if we want to bloat all systems by default or not. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Default font: Transition from DejaVu to Noto
Quoting Gunnar Hjalmarsson (2023-09-13 21:28:00) > Hi Fabian, > > On 2023-09-12 08:24, Fabian Greffrath wrote: > > as has already been stated elsewhere, fontconfig upstream's move to > > Noto as the default font has most probably not been done for > > aesthetical reasons. That is, it is not the "most beautiful font" > > that people "like better" then DejaVu, but the single usable fallback > > font with the widest glyph coverage. > > That might be true. > > > However, I think that the acceptance - or rather lack thereof - of > > the Noto fonts in Debian has indeed to do with the way they are > > currently packaged. There is no pendant to the fonts-dejavu-core > > package which only installs the generic serif and sans-serif flavors. > > Instead, even the fonts-noto-core package installs a full pack of 268 > > (!) font files. This is discussed in detail in #983291 [1]. > > The way they are packaged is absolutely a restriction. How important > restriction it is depends on what you want to achieve. > > If I recall it correctly, the primary suggestion in that bug report is > to split fonts-noto-core into an LCG and an "other" package. Perhaps the primary suggestion, but not the expected future: I maintain the package fonts-noto, and what you refer to is the opinion of Fabian, who disagrees with my views on how to maintain that package. Also, the referenced bugreport is about pain of selecting fonts, and that issue is better addressed in font pickers than by avoiding to install fonts. Notably, the very purpose of the Noto font is to achieve "no tofu" so it is counter to the purpose of that font to omit installing some of its families. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
