Bug#929475: "webext-privacy-badger" should only recommend "fonts-open-sans"

2019-09-28 Thread Protesilaos Stavrou


Markus Koschany  writes:

> On Fri, 24 May 2019 11:33:04 +0300 Protesilaos Stavrou
>  wrote:
>> Package: webext-privacy-badger
>> Version: 2019.2.19-1
>> Severity: wishlist
>>
>> Dear Maintainer,
>>
>> I believe the package "webext-privacy-badger" in Buster should not
>> depend on "fonts-open-sans".  The latter can be defined as a recommended
>> package instead.
>>
>> Looking at Privacy Badger's source code (via `apt download`) it appears
>> that "Open Sans" is only used on "firstRun.html".  That font is defined
>> in /usr/share/webext/privacy-badger/skin/css/firstRun.css
>>
>> A fallback "sans-serif" font is specified as well, meaning that the text
>> will be displayed properly even without package "fonts-open-sans".
>>
>> Thank you for your attention!
>>
>> Best regards,
>> Protesilaos
>
> The open-sans fonts is used by upstream and shipped with the upstream
> sources. We just replace it with a system fonts to reduce the fonts
> duplication in Debian. The intention is really to display the firstRun
> page with this fonts and not with something else and to ensure that we
> have to depend on fonts-open-sans. This is not a bug.
>
> Regards,
>
> Markus Koschany

Dear Markus,

Thank you for the clarification!

All the best,
Protesilaos



Bug#931305: xterm: problems with Greek pi (π) and box-drawing

2019-07-01 Thread Protesilaos Stavrou
Package: xterm
Version: 344-1
Severity: normal

Dear Maintainer,

While using proportional fonts, the Greek letter pi (π) is treated as
a box-drawing character or, more likely, as missing from the
proportional font altogether.  This happens _only at certain point
sizes_ AND/OR _only with specific fonts_.

Scenario 1: Greek pi works, but box-drawing does not


With these settings:

xterm.vt100.faceName: DejaVu Sans Mono
xterm.vt100.faceSize: 10
XTerm.vt100.forceBoxChars: false

The greek letter pi is displayed correctly, but the second vertical line
(drawn with U+2502) is almost the same as the first one (drawn with
U+007C).

Image: 
https://protesilaos.com/assets/images/attachments/xterm_grpi_boxchars_scenario1.png

Scenario 2: Greek pi does not work, but box-drawing does


With these settings:

xterm.vt100.faceName: DejaVu Sans Mono
xterm.vt100.faceSize: 10
XTerm.vt100.forceBoxChars: true

The Greek letter pi is drawn using a fixed-size (bitmap) font.  The
second vertical line is properly displayed using box-drawing characters.

Image: 
https://protesilaos.com/assets/images/attachments/xterm_grpi_boxchars_scenario2.png

Scenario 3: faceSize: 9.5 forceBoxChars: false works for both
-

With these settings:

xterm.vt100.faceName: DejaVu Sans Mono
xterm.vt100.faceSize: 9.5
XTerm.vt100.forceBoxChars: false

Everything appears to work as intended.

Image: 
https://protesilaos.com/assets/images/attachments/xterm_grpi_boxchars_scenario3.png

Scenario 4: Fira Code works using settings from scenarios 1 and 3
-

With these:

xterm.vt100.faceName: Fira Code
xterm.vt100.faceSize: 10
XTerm.vt100.forceBoxChars: false

Or this changed:

xterm.vt100.faceSize: 9.5

Everything seems to work as intended.

Image: 
https://protesilaos.com/assets/images/attachments/xterm_grpi_boxchars_scenario4.png

Scenario 5: forceBoxChars always breaks Greek letter pi (π)
---

With these settings:

xterm.vt100.faceName: Fira Code
xterm.vt100.faceSize: 10
XTerm.vt100.forceBoxChars: true

Regardless of typeface, enabling forceBoxChars will always draw the
letter pi in a bitmap font.

Image: 
https://protesilaos.com/assets/images/attachments/xterm_grpi_boxchars_scenario5.png


-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xterm depends on:
ii  libc6   2.28-10
ii  libfontconfig1  2.13.1-2
ii  libfreetype62.9.1-3
ii  libice6 2:1.0.9-2
ii  libtinfo6   6.1+20181013-2
ii  libutempter01.1.6-3
ii  libx11-62:1.6.7-1
ii  libxaw7 2:1.0.13-1+b2
ii  libxft2 2.3.2-2
ii  libxinerama12:1.1.4-2
ii  libxmu6 2:1.1.2-2+b3
ii  libxpm4 1:3.5.12-1
ii  libxt6  1:1.1.5-1+b3
ii  xbitmaps1.1.1-2

Versions of packages xterm recommends:
ii  x11-utils  7.7+4

Versions of packages xterm suggests:
pn  xfonts-cyrillic  

-- no debconf information



Bug#929475: "webext-privacy-badger" should only recommend "fonts-open-sans"

2019-05-24 Thread Protesilaos Stavrou
Package: webext-privacy-badger
Version: 2019.2.19-1
Severity: wishlist

Dear Maintainer,

I believe the package "webext-privacy-badger" in Buster should not 
depend on "fonts-open-sans".  The latter can be defined as a recommended 
package instead.

Looking at Privacy Badger's source code (via `apt download`) it appears 
that "Open Sans" is only used on "firstRun.html".  That font is defined 
in /usr/share/webext/privacy-badger/skin/css/firstRun.css

A fallback "sans-serif" font is specified as well, meaning that the text 
will be displayed properly even without package "fonts-open-sans".

Thank you for your attention!

Best regards,
Protesilaos

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (500, 'testing'), (200, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages webext-privacy-badger depends on:
ii  fonts-open-sans  1.11-1

Versions of packages webext-privacy-badger recommends:
ii  chromium 73.0.3683.75-1
ii  firefox-esr  60.6.3esr-1

webext-privacy-badger suggests no packages.