artifexsoftware / urw-base35-fonts Goto Github PK

P052 Bold: ѐ (U+0450) is not bold. It looks similar to P052 Roman.

On mac environment the Homebrew and it's extension Caskroom/homebrew-fonts would provide easy installation of URW-fonts, if there is a release zip available like this font has: https://github.com/rsms/inter/releases

https://brew.sh/
https://caskroom.github.io/
https://github.com/caskroom/homebrew-fonts/blob/master/CONTRIBUTING.md

"TeX Gyre Heros" is misspelled as "TeX Gyre Heroes" in the fontconfig files.

In Nimbus Roman, instead of ₣ (U+20A3 FRENCH FRANC SIGN) you see ₢, which would be good as (U+20A2 CRUZEIRO SIGN).

The Fr-ligature for this charcode (as in other fonts) is acceptable instead of ₣ (F with bar). For example, Arial Unicode and Trebuchet use the ligature. Cruzeiro sign is not acceptable.

update_conctact should be update_contact

From texlive point of view, new base35-fonts releases can't be used, because the metrics and kerning tables changed, and glyphs were added. Existing documents would be broken, as these would render diffrently. I assume more glyphs is not that problematic, but is there any chance to bring back the metrics/kerning from
original URW fonts Version 1.05? http://tug.org/svn/texlive/trunk/Master/tlpkg/tlgs/fonts/
If not, it is likely that more metric changes will happen?

My system: Arch Linux 5.8.3-arch-1-1
Package manager: yay (pacman)

I think through a chain of dependencies, this was installed on my system.
(I installed font-manager, which installed vala, which installed graphviz, which installed gsfonts, which lists this repo as the upstream URL)

When I installed font-manager, my default system fonts (such as the monospace font used in my terminal and dmenu) were overridden from Noto to Nimbus. I checked that using

• fc-match monospace
• fc-match sans-serif
• fc-match serif

which all returned a Nimbus variant.

I found out that gsfonts was the package that installed Nimbus on my system.
(After I uninstalled gsfonts, my fonts thankfully went back to normal; checking with fc-match returns Noto variants again.)

Is this expected behavior? If it is, I find it quite intrusive. It took me a while to track down the problem on my system.

Could this be related to #13 ?

Nimbus Mono is supposedly metrically compatible with Courier, but Courier displays 'ff' as two separate 'f' characters, Nimbus Mono prints it as a ligature that takes up the same space as a single 'f' character. Likewise for other ligatures. When Nimbus Mono is used as a substitute for Courier on the assumption that they are metric-compatible, it breaks layouts.

Should the ligatures be disabled (except when they are specifically requested, e.g. when U+FB00 ('ff') is used), or should the font instead not be treated as metric-compatible? If you prefer to leave the ligatures as they are, please let me know and I will instead file bugs against those places that list the font as metric-compatible.

I apologize for posting what is probably the dumbest font bug title ever. But it's true! Nimbus Regular at 10-12pt is like 1px too high in every application, and judging from FontForge, it looks like the rest of the URW OTF fonts are too high as well.

Here is Nimbus Regular (installed on archlinux from stock gsfonts, version 20170829-1), Tex Gyre Heros (another metric-compatible for Helvetica), and Source Sans Pro at 13px size displaying the Wikipedia page for the Higgs Boson in Firefox (Linux). Compared to the other two fonts, Nimbus Regular is just too.. high.

Here's a screenshot of FontForge showing some glyphs from /usr/share/fonts/gsfonts/NimbusSans-Regular.otf. All of the URW fonts I've tried to open in FontForge have their accents clipped off; none of the other fonts I've tried are doing this.

afii10086 ф:
too wide in NimbusSans-Italic
too wide in NimbusSans-BoldItalic
a touch too wide in NimbusSans-Bold and NimbusSans-Regular

uni040D Ѝ:
too wide in URWGothic-Book

uni0450 ѐ:
shifted to the right in NimbusSansNarrow-Oblique
shifted to the right in NimbusSansNarrow-BoldOblique

uni0462 Ѣ:
too narrow in URWBookman-DemiItalic
too narrow in C059-Italic

uni0463 ѣ:
too wide in NimbusRoman-BoldItalic
too wide in NimbusSans-Italic
too wide in NimbusSans-BoldItalic

uni0472 Ѳ:
too wide in URWGothic-DemiOblique

afii10084 т (already fixed in #28):
too wide in NimbusSans-Italic
too wide in NimbusSans-BoldItalic

To focus on these glyphs, I use ftview -f671 32 ...

Bug 1871377 reported to Ubuntu:

It seems that cyrillic small letter `te` (afii10084) has wrong glyph in italic and bold Italic style: width is too big.
This issue presented in OpenType and Type1 URW Nimbus Sans fonts distribution.

I suggest to replace with the glyph of greek small `tau` letter.

Attaching here the screenshots of some example words contain small letter `te` with original (wide) and replaced glyph.

See screen shots and more info in the files and comments on the Ubuntu bug report.

The P052 fonts are missing blue zones for x-height, etc., which makes the hinting of the OTFs and Type1 fonts not work very well.

Note the inconsistent height of e.g. e vs. r.

In the Nimbus Roman font, the character ₤ (U+20A4 LIRA SIGN) looks like
"zł". It should look similar to £ (U+00A3 POUND SIGN) instead.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025267

The entire Nimbus Mono PS family shows something resembling ℞ instead of reversed quote U+201B.

URWGothic Demi and Demi Oblique have quotereversed in mismatched style.

Several of the AFM files list a non-empty bounding box for the "space" character. For example, NimbusRoman-Regular.afm has the following:

C 32 ; WX 250 ; N space ; B 125 0 125 0 ;

In contrast, the AFM specification explains the use of B as follows:

... If a character makes no marks on the page (for example, the space character), this field reads B 0 0 0 0 ...

I believe that B 125 0 125 0 above should be replaced with B 0 0 0 0 (and similar for the other fonts).

I need to install d050000l and s050000l, but windows asks for pbf and pfm
Those are not included in the pack ....
TIA

Instead of U+0450 ѐ, the entire NimbusMonoPS family incorrectly shows Ѵ.
Instead of U+04E9 ө, the entire NimbusMonoPS family incorrectly shows џ.

On my Ubuntu 20.04 system, this file shows up badly, apparently because "Century" is being substituted by Deja Vu Sans, even though I have the C059 font installed on my system.

john@ovo:~$ fc-match Century
DejaVuSans.ttf: "DejaVu Sans" "Book"

I wonder if this is because the fontconfig information for C059 needs to be expanded in some way? Apologies if I am asking this question in the wrong place.

Hello,

I use archlinux,

with the last version of gsfonts ( 20170829-1 ) I notice that numbers are bad rendered if the font "nimbus sans regular" is used, for example the string "2017", the "1" will be badly rendered,

if I use the previous version of gsfonts ( 20170727-1 ) then all is ok,

you can find a hmtl source code which shows this bug
test_nimbus_sans_regular.zip

The OTF fonts have the "preview/print only" flags set, c.f. the OpenType standard:
https://learn.microsoft.com/en-us/typography/opentype/spec/os2#fstype

There’s just not enough space around the EM dash and its neighbors. Could it be shortened?

This is a monospaced font family. Σ looks too close to the right margin and too far from the left one. This is especially noticeable in the context of all caps.

First, these glyph images are mapped correctly to their appropriate unicode. The issue here is the confusing glyph names, which stems form ambiguous Adobe Glyph List.

      U+015e => 266 Scedilla
      U+015f => 345 scedilla
      U+0162 => 371 Tcommaaccent
      U+0163 => 372 tcommaaccent
      U+0218 => 370 Scommaaccent
      U+0219 => 318 scommaaccent
      U+021a => 273 uni021A
      U+021b => 325 uni021B

It is more appropriate to rename U+0162 and U+0163 as Tcedilla and tcedilla.

The true ?commaaccent glyphs U+0218, U+0218, U+021A, and U+021B, could use the recommended uni-names or the descriptive commaaccent names, as long as they are consistent.

It is probably not a good idea to italicize ∏ (U+220F N-ARY PRODUCT) in URW Bookman. At least, it should be consistent with ∑ (U+2211 N-ARY SUMMATION). Nimbus Sans, Nimbus Sans Narrow, Nimbus Mono PS mess up baseline or size of these glyphs.

Also in URW Bookman, ϕ (U+03D5 GREEK PHI SYMBOL) is identical to φ (U+03C6 GREEK SMALL LETTER PHI). Usually the former has a closed form. This distinction might be important in some math formulas.

Hi guys,
D050000l by some reason is preferred font for fantasy family. According to https://www.w3.org/Style/Examples/007/fonts.en.html this family used for decorative fonts, and we have this:

<alias>
<family>Impact</family>
<default><family>fantasy</family></default>
</alias>

somewhere in fontconfig and this:

        <alias>
                <family>fantasy</family>
                <prefer>
                        <family>Impact</family>
                        <family>Copperplate Gothic Std</family>
                        <family>Cooper Std</family>
                        <family>Bauhaus Std</family>
                </prefer>
        </alias>

in 60-latin.conf,
so installing urw-base35-fonts results in incorrect subtitution Impact -> D050000l.
UPD: I do not have Impact installed, but still the following behavior is very confusing:

[admin@check-centos7-new conf.d]$ fc-match impact
D050000L.otf: "D050000L" "Regular"

Am i missing something?

Hi guys,

something is wrong with your fontconfig rules files, i.e. either with the rules themselves or with the priority that you suggest for installing them. Let's have a look at Nimbus Mono PS specifically.

This happens on my system before installing any of your fontconfig rules:

> fc-match monospace
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"

This is the expected result, we will lates see why. This, however, is what happens once I install your urw-nimbus-mono-ps.conf fontconfg rules file as /etc/fonts/conf.d/30-urw-nimbus-mono-ps.conf:

> fc-match monospace
NimbusMonoPS-Regular.t1: "Nimbus Mono PS" "Regular"

As you can see, due to this rule, Nimbus Mono PS does a system-wide hijack of the "monospace" fontconfig generic, which has an immediate effect on e.g. my terminal and text editor. This is neither expected nor -- I hope -- intended.

It all happens because of this specific rule in the urw-nimbus-mono-ps.conf file:

  <!-- Generic name aliasing -->
  <alias>
    <family>monospace</family>
    <prefer>
      <family>Nimbus Mono PS</family>
    </prefer>
  </alias>

Please note that (a variant of) this rule is already in fontconfig's upstream rule file in /etc/fonts/conf.d/60-latin.conf:

        <alias>
                <family>monospace</family>
                <prefer>
                        <family>Bitstream Vera Sans Mono</family>
                        <family>DejaVu Sans Mono</family>
                        <family>Inconsolata</family>
                        <family>Andale Mono</family>
                        <family>Courier New</family>
                        <family>Cumberland AMT</family>
                        <family>Luxi Mono</family>
                        <family>Nimbus Mono L</family>
                        <family>Nimbus Mono</family>
                        <family>Nimbus Mono PS</family>
                        <family>Courier</family>
                </prefer>
        </alias>

As you can see, there is a specific priority in the monospace fonts, probably based on the (admittedly subjective) suitability as a terminal font -- and DejaVu Sans Mono comes clearly before Nimbus Mono PS. However, by installing the urw-nimbus-mono-ps.conf file with a higher priority than 60-latin.conf, this ordering is messed up and Nimbus Mono PS is installed with an unsuitably high priority.

I see two ways out of this unfortunate situation: Either, you recommend to install the fontconfig rules files with a priority lower than that of 60-latin.conf, e.g. 61, or you remove the redundant rules that are already part of fontconfig upstream's rules set out of your fontconfig rules files.

Compared to gsfonst 8.11, there is no glyph "commaaccent" in the current urw-base35-fonts release.
I currently have no issue with that, but wonder if this intentional.

Uneven diaeresis ◌̈ in Greek and Cyrillic ranges shows dots at different heights. This includes U+03CA, U+03CB, U+0451, and U+0457. The Latin range does not have this problem. Also other fonts in the family do not have this problem. Therefore, it is probably not on purpose.

Hi guys,

I plan to self-host fonts on a website, among others one of the URW-base35 fonts. The AGPLv3 license would allow me to redistribute it.

Now I need to convert the font from OTF to WOFF2 format, for which I use Fontforge.

However, in Fontforge, the font info window gives the following copyright notice (thus embedded in the .otf file):
"
Copyright (URW)++,Copyright 2014 by (URW)++ Design & Development
"
Does this simply mean that this field was not updated when URW released the font under AGPLv3? And may I change that field into AGPLv3 myself? Or should I doubt whether I am entitled to change the format and/or distribute the font on a server?

Any other fields to consider?