https://bugzilla.redhat.com/show_bug.cgi?id=1449166
Bug ID: 1449166
Summary: Shape for Serbian Cyrillic BE Wrong
Product: Fedora
Version: rawhide
Component: liberation-fonts
Assignee: psatpute(a)redhat.com
Reporter: rosella.capriotti(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com
Created attachment 1277346
--> https://bugzilla.redhat.com/attachment.cgi?id=1277346&action=edit
DELTA and Serbian BE in Liberation 2
Description of problem:
On Lubuntu 17.04 & Libreoffice 5.3.1.2, the shape of Serbian Cyrillic BE in
Liberation Serif v.2 looks uncannily like Greek DELTA. The shape in version 1
seems to me more appropriate.
I added two attachments for the two versions of Liberation Serif: on both Greek
DELTA is on the right for the sake of comparison.
Regards
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1498269
Bug ID: 1498269
Summary: Noto Color Emoji and Noto Emoji fixed fonts cause a X
error in a tcl/tk script
Product: Fedora
Version: 26
Component: google-noto-fonts
Severity: high
Assignee: psatpute(a)redhat.com
Reporter: jlc(a)cfl.rr.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
psatpute(a)redhat.com, pwu(a)redhat.com
Created attachment 1333924
--> https://bugzilla.redhat.com/attachment.cgi?id=1333924&action=edit
test script do demonistrate emoji fix font causing an X error
Description of problem:
The NCID (Network Caller ID) client is written in tcl/tk. When the
google-noto-emoji-fonts became part of the standard install for Fedora, the
ncid client would cause an X error and crash every time it scanned for fixed
fonts. The attached script was written to determine and verify the problem.
Version-Release number of selected component (if applicable):
google-noto-emoji-fonts-20170827-1.fc26.noarch
How reproducible:
Reproducible every time test script run on Fedora 26 and also Fedora 25.
Steps to Reproduce:
1. run attached test script
2.
3.
Actual results:
X Error of failed request: BadLength (poly request too large or internal Xlib
length error)
Major opcode of failed request: 138 (RENDER)
Minor opcode of failed request: 20 (RenderAddGlyphs)
Serial number of failed request: 476
Current serial number in output stream: 539
Expected results:
Expected script not to cause an X error and crash.
Additional info:
Uncomment the two Noto Emoji font lines in testfonts.tk to not get the X error.
The bug is also reported at https://core.tcl.tk/tk/tktview/3767882e066523dc9ae4
but it is considered a font problem not a tk problem.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1427550
Bug ID: 1427550
Summary: Adding additional Glyphs in Tamil
Product: Fedora
Version: rawhide
Component: lohit-tamil-fonts
Severity: medium
Assignee: psatpute(a)redhat.com
Reporter: nsesha92(a)yahoo.co.in
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, psatpute(a)redhat.com
Created attachment 1258398
--> https://bugzilla.redhat.com/attachment.cgi?id=1258398&action=edit
Svarita Deerga Svarita Anudatta eg
Description of problem:
This is not a bug, but enhancement request.
Tamil language script is also used for writing other language text such as
Sanskrit, Hindi, Malayalam, Telugu and Kannada in the form of transliteration.
However Tamil script and the associated Unicode range U0B80-U0BFF does not
contain many characters that are available in these other languages - mainly
the Devanagari Extended unicode UA8E0 and Devanagari Vedic
Extentions unicode U1CD0 series.
Some such requests that I have come across in my FB and other groups:
1. How can I include the signs like lines above the letters as shown in the
picture. This is required to show the swaram i.e. high or low pitch of
pronouncing the letter/word as in Sanskrit. This kind of lines are used in
Sanskrit also.
2. I need to type musical notations in Tamil Using MSword processor. To
indicate octave we put a dot on top or bottom of the letter. how to add ?
--- My answer for above point 2: dot above = anuswara, dot below = nukta, Lohit
Tamil does not contain nukta, but includes anuswara (U+0B82). ---
While its lot easier to juggle around in Linux based systems by switching
between different fonts, its very difficult in MS based applications.
Hence, I am requesting that 9 such frequently used Glyphs be 'added' to the
existing Lohit Tamil font. The existing Glyphs from Lohit-Devanagari.ttf can be
'leveraged' for this, no need to reinvent the wheel.
Replace:
U+0310 COMBINING CANDRABINDU >>> replace with VEDIC TONE CANDRABINDU /
anunasika U+0901, thats in Devanagari range, to be consistent with all other
scrips.
Add:
Signs:
Visarga U+0903 ( as separate and distinct, in addition to Tamil Visarga U+0B83
)
AVAGRAHA U+093D
CANDRABINDU VIRAMA U+A8F3
Combining signs/marks with Anchoring:
NUKTA U+093C
VEDIC TONE UDATTA / SVARITA U+0951
VEDIC TONE ANUDATTA U+0952
VEDIC TONE PRENKHA U+1CD2
VEDIC TONE DOUBLE/Deerga SVARITA U+1CDA
VEDIC TONE CANDRA U+1CF4
Version-Release number of selected component (if applicable):
How reproducible:
Not a bug, but enhancement request.
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1336042
Bug ID: 1336042
Summary: Liberation Fonts not displayed correctly
Product: Fedora
Version: 24
Component: liberation-fonts
Severity: high
Assignee: psatpute(a)redhat.com
Reporter: freepenguin84(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com
Created attachment 1157360
--> https://bugzilla.redhat.com/attachment.cgi?id=1157360&action=edit
Screenshots to show the difference between Fedora 22 and 23/24
Description of problem:
Liberation Fonts are not being diplayed correctly. This is obvious on websites
where the text is shifted some pixel up compared to Fedora 22 and other OSes.
Fedora 23 has the same issue.
The source files for liberation font is the same in Fedora 22-24 but the output
*.ttf files are different. Installing the RPMs from Fedora 22 in Fedora 24
fixes the problem. Maybe the output has changed due to updated build tools?
Version-Release number of selected component (if applicable):
1.07.4
How reproducible:
Open Webpage in Firefox or Google Chrome
Steps to Reproduce:
Open https://github.com/solus-project/budgie-desktop in Firefox
Actual results:
Text is shifted upwards besides the images (see attached screenshot)
Expected results:
Text aligned with images (see attached screenshot)
Additional info:
https://plus.google.com/+ViktorPankraz/posts/L8KVUGEbHxz
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1380754
Bug ID: 1380754
Summary: Missing kerning pair for the Czech language ďá
Product: Fedora
Version: rawhide
Component: scholarsfonts-cardo-fonts
Assignee: pnemade(a)redhat.com
Reporter: mcepl(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, pnemade(a)redhat.com
Created attachment 1206277
--> https://bugzilla.redhat.com/attachment.cgi?id=1206277&action=edit
illustration of the problem
Description of problem:
This is just to record the unfortunate missing kerning pair for ďá (used in
Czech, for example “devil” is “ďábel”). I will try to investigate which other
kerning pairs are missing.
Version-Release number of selected component (if applicable):
scholarsfonts-cardo-fonts-1.045-12.el7.noarch
How reproducible:
100%
Steps to Reproduce:
1.print the standard Czech pangram “Příliš žluťoučký kůň úpěl ďábelské ódy.”
2.
3.
Actual results:
space between ď and á in the word “ďábelské” is awful
Expected results:
It shouldn't be
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Please rebuild using external Adobe CMap and AGLFN data
https://bugzilla.redhat.com/show_bug.cgi?id=525872
Summary: Please rebuild using external Adobe CMap and AGLFN
data
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: qt
AssignedTo: than(a)redhat.com
ReportedBy: nicolas.mailhot(a)laposte.net
QAContact: extras-qa(a)fedoraproject.org
CC: rdieter(a)math.unl.edu, than(a)redhat.com,
kevin(a)tigcc.ticalc.org,
fedora-fonts-bugs-list(a)redhat.com, ltinkl(a)redhat.com
Blocks: 182235,473302
Classification: Fedora
Description of problem:
The Debian fonttool packager noticed a problem in fonttool's embedded Adobe
CMap and AGLFN data and got Adobe to release them under a good license
This data is embeded in many packages, including yours
Please rebuild your package using an external shared Adobe CMap and AGLFN data
package
FE-LEGAL since this was all triggered by a legal checl Debian-side
See also
http://bonedaddy.net/pabs3/log/2009/09/24/adobe-data-freed/http://lwn.net/Articles/354360/http://opensource.adobe.com/wiki/display/cmap/CMap+Resources
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1094779
Bug ID: 1094779
Summary: No Cyrillic Italic Glyphs for Sans, Sans Narrow and
Mono
Product: Fedora
Version: rawhide
Component: liberation-fonts
Assignee: psatpute(a)redhat.com
Reporter: alescesc1986(a)yahoo.it
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com
It's wrong for Liberation Sans, Sans Narrow and Mono to have specific italic
glyphs in the Cyrillic range provided that the Latin range has slanted glyphs.
For the sake of consistency, slanted glyphs should be implemented in the
Cyrillic range too.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=k7Die5I6Dr&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1464310
Bug ID: 1464310
Summary: Tilded G not works with Liberation Sans and Serif
Product: Fedora
Version: rawhide
Component: liberation-fonts
Assignee: psatpute(a)redhat.com
Reporter: shanshandehongxing_1234(a)hotmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com
Description of problem:
Guarani letter G̃ does not works if I use Liberation Sans and Serif, this
letter requiring combining tilde.
Steps to Reproduce:
1. Coping this letter from https://en.wikipedia.org/wiki/Guarani_alphabet
2. Pasted into LibreOffice
3. Switch font face to Liberation Sans or Liberation Serif
Actual results:
With Liberation Sans/Serif tilded G does not works as expected.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1096336
Bug ID: 1096336
Summary: Liberation 2.00.x missing unicode hyphen (U+2010)
Product: Fedora
Version: rawhide
Component: liberation-fonts
Assignee: psatpute(a)redhat.com
Reporter: elbart(a)gmx.de
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com
Description of problem:
The liberation-fonts 2.00.0 and 2.00.1 are missing the unicode hyphen (U+2010).
Versions 1.07.4 and older have that glyph.
Version-Release number of selected component (if applicable):
2.00.1
The regressing commit is
https://git.fedorahosted.org/cgit/liberation-fonts.git/commit/?id=5feb93675…
(slow!)
प्रविण सातपुते "sfd file converted from ttf"
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=N1bvIUoqeP&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1084493
Bug ID: 1084493
Summary: Missing MIDDLE DOT (u+00B7) glyph for Liberation Sans
Italic
Product: Fedora
Version: rawhide
Component: liberation-fonts
Assignee: psatpute(a)redhat.com
Reporter: jmontane(a)softcatala.org
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com
Created attachment 882714
--> https://bugzilla.redhat.com/attachment.cgi?id=882714&action=edit
Screenshot showing the bug
Description of problem:
In Windows, there is no glyph for MIDDLE DOT (U+00B7) when using Liberation
Sans Italic, an empty space is showed.
Version-Release number of selected component (if applicable):
2.00.1
How reproducible:
Install Liberation Sans Italic files in a Windows machine (tested in Windows 7
32 and 64 bits). The esay way is installing LibreOffice 4.2, :)
Steps to Reproduce:
1. Open a new document LibreOffice Writer
2. Type "cel·la" (cell) "·" is U+00B7
3. Select "cel·la" text and set format as "Libreration Sans, Italic".
Actual results:
4.- "cel la" is showed in italics,you can copy and paste and set other font.
Expected results:
5.- "cel·la"
Additional info:
U+00B7 is a used character for Catalan text. So, please, fix this issue.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=1MRhFWVfJa&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1072095
Bug ID: 1072095
Summary: Liberation Sans renders most Latin combining
characters incorrectly
Product: Fedora
Version: 20
Component: liberation-fonts
Assignee: psatpute(a)redhat.com
Reporter: rkaldari(a)wikimedia.org
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com
Created attachment 870161
--> https://bugzilla.redhat.com/attachment.cgi?id=870161&action=edit
Comparison between Helvetica, Arimo, and Liberation Sans
Description of problem:
Liberation Sans renders most Latin Unicode combining characters incorrectly.
These are the diacritics and tie characters in the Unicode range U+0300 to
U+FE2F (https://en.wikipedia.org/wiki/Combining_character) In particular:
1. The diacritics do not take into account the width or height of the paired
character (which I imagine is a kerning issue)
2. Tie characters are always positioned incorrectly. They are supposed to
visually tie two characters together, but in Liberation Sans they are simply
centered under the 2nd character.
Version-Release number of selected component (if applicable):
version 2.00.1
How reproducible:
Steps to Reproduce:
1. Install Liberation Sans
2. Go to https://en.wikipedia.org/wiki/User:Kaldari/Font_test
Actual results:
Diacritics and ties are a mess.
Expected results:
See Helvetica example in attached file.
Additional info:
The best way to understand this bug is to look at the attached file
(comparison.png).
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=xTTdgh7sKr&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1088033
Bug ID: 1088033
Summary: Text Figures for Liberation Fonts
Product: Fedora
Version: rawhide
Component: liberation-fonts
Assignee: psatpute(a)redhat.com
Reporter: alescesc1986(a)yahoo.it
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com
Hello Pravin,
I was wondering whether you might consider adding text figures to your fonts.
That'd be great and I don't think it'll take you long.
Regards
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=tODxrdeHtL&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1375061
Bug ID: 1375061
Summary: RFE: try switching to Liberation Fonts 2 again
Product: Fedora
Version: rawhide
Component: liberation-fonts
Assignee: psatpute(a)redhat.com
Reporter: fedora(a)leemhuis.info
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com
Description of problem:
The freetype maintainer in
https://www.freetype.org/freetype2/docs/subpixel-hinting.html recommends "using
the Liberation family of fonts (version 2 and up, important!)" and criticises
Fedora because it still ships version 1.x. I think it's time to try switching
to v2 again. We tried that a few years ago
(https://fedoraproject.org/wiki/Features/Liberation_Fonts_2 ) and stopped it
then due to problems (see Bug 856239); but from above recommendation it sounds
like the problems we faced might be gone fixed in between.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1090631
Bug ID: 1090631
Summary: Please set TT_NAME_ID_PREFERRED_FAMILY for Liberation
fonts
Product: Fedora
Version: rawhide
Component: liberation-fonts
Assignee: psatpute(a)redhat.com
Reporter: rhughes(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com
Description of problem:
At the moment the TT_NAME_ID_PREFERRED_FAMILY is not set on any of the
Liberation fonts. As I understand it, TT_NAME_ID_PREFERRED_FAMILY is supposed
to be the same for all files in the same high-level family, and this seems to
be what most other fonts do in Linux. For the next release could you please set
the PreferredFamily key to just "Liberation" in all 10 files. This allows
component installers like gnome-software to group the fonts together rather
than showing them as separate entries and should have no other effects.
Thanks,
Richard.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Zd611y9wUR&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1009650
Bug ID: 1009650
Summary: Some Serbian glyphs seem to be Latin glyph
Product: Fedora
Version: 19
Component: liberation-fonts
Assignee: psatpute(a)redhat.com
Reporter: alescesc1986(a)yahoo.it
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com
Hello,
I have a problem with Italic DE and GE: when I copy them from a pdf produced by
XeLaTeX, they are pasted respectively as Latin G and I WITH MACRON. I'm
puzzled, why does this happen?
By the way, other Serbian glyphs aren't copied at all, but they told me this is
XeLaTeX's fault, not font-dependent.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=WUlCWOjbqa&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1013949
Bug ID: 1013949
Summary: Problematic shapes for some letters of the macedonian
alphabet.
Product: Fedora
Version: 20
Component: liberation-fonts
Severity: high
Assignee: psatpute(a)redhat.com
Reporter: pvelkovski(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com
Created attachment 805748
--> https://bugzilla.redhat.com/attachment.cgi?id=805748&action=edit
Shoes how the letters look like, and what they should look like.
Description of problem:
The shape of the Regular (Normal) "Cyrillic
macedonian small letter be" looks. It looks like the italic form minus the
slant which is wrong!
Also the letters "macedonian cyrilic ghe" and "macedonian cyrillic gje" look
inconsistent in italic form. The "macedonian cyrilic gje" should look same as
"macedonian cyrilic ghe" with an added accent.
I'm attaching a pdf file that should explain the problem.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=UhMfVgfR8e&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1014357
Bug ID: 1014357
Summary: U+266B incorrect glyph with extra beam
Product: Fedora
Version: rawhide
Component: liberation-fonts
Assignee: psatpute(a)redhat.com
Reporter: fabian+redhat(a)greffrath.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com
Originally reported as Debian #724839 [1] by Drake Wilson:
"
Using gucharmap 1:3.8.2-2 to view Liberation Serif characters with "Show only
glyphs from this font" enabled, the glyph for U+266B BEAMED EIGHTH NOTES shows
what is clearly beamed sixteenth notes instead; it should have only one beam
rather than two. FontForge confirms this after opening
LiberationSerif-Regular.ttf with SHA-256 =
ea76595ed32ec4bb117fc715e393b4cca3d42cabe53101baec6bbbeb800fa26a.
The glyph for U+266C BEAMED SIXTEENTH NOTES is correct.
"
The bug has been reported against version 2.00.1, ut I have checked with 1.07.3
and it is also present in this version.
Best regards,
Fabian
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724839
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=hFqMLHng7w&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1195216
Bug ID: 1195216
Summary: To wide macron for Liberation Sans Narrow fonts
Product: Fedora
Version: 20
Component: liberation-fonts
Assignee: psatpute(a)redhat.com
Reporter: eko(a)lanet.lv
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com
Created attachment 994356
--> https://bugzilla.redhat.com/attachment.cgi?id=994356&action=edit
Too wide macron
Description of problem:
The macron (uni02C9) symbol in Liberation Sans Narrow fonts is too wide.
Version-Release number of selected component (if applicable):
1.07.4.
How reproducible:
100%
Steps to Reproduce:
Look at following letters with Liberation Sans Narrow fonts:
āēīōūĀĒĪŌŪ
Actual results:
See attached image Liberation_Sans_Narrow-old.png.
Expected results:
See attached image Liberation_Sans_Narrow-new.png.
Additional info:
A suggested path will be attached.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=sozGaFqcCe&a=cc_unsubscribe
http://bugs.freedesktop.org/show_bug.cgi?id=18928
Summary: RFE: add a gfx preview to font packages
Product: PackageKit
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: General
AssignedTo: richard(a)hughsie.com
ReportedBy: nicolas.mailhot(a)laposte.net
CC: fedora-fonts-bugs-list(a)redhat.com
The best way for a user to select a font is to show it to him.
For this reason font sites commonly provide bitmap preview images or so-called
specimen files (typically in PDF form) that showcase the font capabilities.
http://gonzo.uni-weimar.de/~gerner/fonts/YanoneKaffeesatz.pdfhttp://www.ascendercorp.com/pdf/Droid_fonts.pdf
Packagekit should do the same.
The image should be a pangram
http://en.wikipedia.org/wiki/List_of_pangrams
in the main unicode blocks the font supports
The specimen may include unicode coverage info, glyph table, etc
For more info ask on fedora-fonts-list at redhat.com
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.freedesktop.org/show_bug.cgi?id=20120
Summary: Display font script coverage info in the UI
Product: PackageKit
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: General
AssignedTo: richard(a)hughsie.com
ReportedBy: nicolas.mailhot(a)laposte.net
CC: fedora-fonts-bugs-list(a)redhat.com
To make fonts auto-install work coverage auto-provides are being added to font
packages.
However, those provides are not only useful for auto-installation.
Users are just as interested to know they can use a font package to render
Greek or Catalan or Arabic when browsing the package repository manually.
Please transform those provides in user-friendly information added to font
package descriptions in packagekit GUI frontends.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.freedesktop.org/show_bug.cgi?id=18725
Summary: RFE: allow merging of legacy font family names
Product: fontconfig
Version: 2.6
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: library
AssignedTo: keithp(a)keithp.com
ReportedBy: nicolas.mailhot(a)laposte.net
CC: fedora-fonts-bugs-list(a)redhat.com
Historically font formats only allowed four faces regular, bold, italic, bold
italic. You had to use a separate font family to distribute condensed, heavy
etc variants
This has changed (cf http://blogs.msdn.com/text/attachment/2249036.ashx ) and
modern fonts such as DejaVu include all faces under a single family name.
Applications such as OO.o are being fixed to handle multifaced fonts
Unfortunately there are still many historic fonts in the wild distributed in
several sets of four faces (gs fonts, arial narrow, arial bold, etc). Those
fonts currently appear under different family names in fontconfig-using apps.
This is perturbing to users, since the same faces of historic and modern fonts
are not handled the same way. Microsoft did some sort of magic in uniscribe to
hide this distinction (irrelevant to users).
Please provide a documented config pattern for font distributors that enables
them to declare to fontconfig "font family A and font family B are the same,
please expose all the associated faces under A name to users".
(of course an application asking explicitely for B should still get it, but
users would only see A in font lists)
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.freedesktop.org/show_bug.cgi?id=18723
Summary: RFE: fontconfig-level locl patching
Product: fontconfig
Version: 2.6
Platform: Other
OS/Version: All
Status: NEW
Severity: enhancement
Priority: medium
Component: library
AssignedTo: keithp(a)keithp.com
ReportedBy: nicolas.mailhot(a)laposte.net
CC: fedora-fonts-bugs-list(a)redhat.com
Due to Han unification and other similar stuff parts of some fonts may not be
suitable for all locales.
This is handled by the locl flag in modern opentype fonts.
However there are still many non-opentype fonts in the wild, and it is not
possible to convert them all at once (when the license permits it).
There should be a way in fontconfig for font distributors to patch in via a
config file the locl characteristics of a font.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.freedesktop.org/show_bug.cgi?id=22338
Summary: Make fc-query warn about non-WWS compliant fonts
Product: fontconfig
Version: 2.6
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: library
AssignedTo: freedesktop(a)behdad.org
ReportedBy: nicolas.mailhot(a)laposte.net
QAContact: keithp(a)keithp.com
CC: fedora-fonts-bugs-list(a)redhat.com
(it would be nice if there was a fc-query component in fontconfig BTW)
Since MS' WWS naming model makes stuff simpler for application authors, and
will be required in new window code, it would be mighty nice if fc-query warned
in its general report if a font file didn't respect this model.
Respecting the WWS model is declaring fields 21 and 22 or 16 in 17 in ways that
respect WWS (only weight, width and slant in sytles)
This way we can point FLOSS authors to fc-query as linting tools and promote
font naming our apps can handle easily
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.freedesktop.org/show_bug.cgi?id=18727
Summary: RFE: allow use of iso 15924 codes
Product: fontconfig
Version: 2.6
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: library
AssignedTo: keithp(a)keithp.com
ReportedBy: nicolas.mailhot(a)laposte.net
CC: fedora-fonts-bugs-list(a)redhat.com
There are a lot of scripts in the wild and the most accurate standard way to
specify them is using iso 15924 codes
http://www.unicode.org/iso15924/iso15924-codes.html
Please make it possible to write font patterns using iso 15924 codes in
fonts.conf
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1271792
Bug ID: 1271792
Summary: repo-font-audit invalid option errors
Product: Fedora
Version: 23
Component: fontpackages
Assignee: nicolas.mailhot(a)laposte.net
Reporter: kvolny(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
nicolas.mailhot(a)laposte.net, paul(a)frixxon.co.uk,
tagoh(a)redhat.com
Description of problem:
Following https://fedoraproject.org/wiki/Font_package_lifecycle#2.a the step
with repo-font-audit doesn't work for me as the tool reports many "invalid
option" errors for coreutils programs it obviously tries to use.
Version-Release number of selected component (if applicable):
fontpackages-tools-1.44-14.fc23.noarch
How reproducible:
always
Steps to Reproduce:
0. # dnf install fontpackages-tools createrepo rpm-build
... whatever needed
1. cd ~/rpmbuild/SRPMS
2. wget https://kvolny.fedorapeople.org/comic-neue-fonts-2.2-1.fc23.src.rpm
3. rpmbuild --rebuild comic-neue-fonts-2.2-1.fc23.src.rpm
4. cd ../RPMS/noarch
5. mkdir /tmp/testrepo
6. mv comic*rpm /tmp/testrepo
7. createrepo /tmp/testrepo
8. repo-font-audit testrepo file:///tmp/testrepo
Actual results:
Looking for packages:
— with font metadata…
Error: 'Package' object has no attribute 'packagesize'
— that include files with common font extensions…
— that use the core X11 protocol…
Inspecting packages:
– -. ◔mkdir: invalid option -- '.'
Try 'mkdir --help' for more information.
/bin/repo-font-audit: line 388: cd: -.: invalid option
cd: usage: cd [-L|[-P [-e]] [-@]] [dir]
curl: (3) [globbing] bad range specification in column 90
◑rpm2cpio: *.rpm: No such file or directory
◕cat: invalid option -- '.'
Try 'cat --help' for more information.
cpio: premature end of archive
cat: invalid option -- '.'
Try 'cat --help' for more information.
touch: invalid option -- '.'
Try 'touch --help' for more information.
cat: invalid option -- '.'
Try 'cat --help' for more information.
cpio: premature end of archive
rm: invalid option -- '.'
Try 'rm ./-..cpio' to remove the file '-..cpio'.
Try 'rm --help' for more information.
● sed: invalid option -- '.'
Usage: sed [OPTION]... {script-only-if-no-other-script} [input-file]...
-n, --quiet, --silent
suppress automatic printing of pattern space
-e script, --expression=script
add the script to the commands to be executed
-f script-file, --file=script-file
add the contents of script-file to the commands to be executed
--follow-symlinks
follow symlinks when processing in place
-i[SUFFIX], --in-place[=SUFFIX]
edit files in place (makes backup if SUFFIX supplied)
-c, --copy
use copy instead of rename when shuffling files in -i mode
-b, --binary
does nothing; for compatibility with WIN32/CYGWIN/MSDOS/EMX (
open files in binary mode (CR+LFs are not treated specially))
-l N, --line-length=N
specify the desired line-wrap length for the `l' command
--posix
disable all GNU extensions.
-r, --regexp-extended
use extended regular expressions in the script.
-s, --separate
consider files as separate rather than as a single continuous
long stream.
-u, --unbuffered
load minimal amounts of data from the input files and flush
the output buffers more often
-z, --null-data
separate lines by NUL characters
--help
display this help and exit
--version
output version information and exit
If no -e, --expression, -f, or --file option is given, then the first
non-option argument is taken as the sed script to interpret. All
remaining arguments are names of input files; if no input files are
specified, then the standard input is read.
GNU sed home page: <http://www.gnu.org/software/sed/>.
General help using GNU software: <http://www.gnu.org/gethelp/>.
sed: invalid option -- '.'
Usage: sed [OPTION]... {script-only-if-no-other-script} [input-file]...
-n, --quiet, --silent
suppress automatic printing of pattern space
-e script, --expression=script
add the script to the commands to be executed
-f script-file, --file=script-file
add the contents of script-file to the commands to be executed
--follow-symlinks
follow symlinks when processing in place
-i[SUFFIX], --in-place[=SUFFIX]
edit files in place (makes backup if SUFFIX supplied)
-c, --copy
use copy instead of rename when shuffling files in -i mode
-b, --binary
does nothing; for compatibility with WIN32/CYGWIN/MSDOS/EMX (
open files in binary mode (CR+LFs are not treated specially))
-l N, --line-length=N
specify the desired line-wrap length for the `l' command
--posix
disable all GNU extensions.
-r, --regexp-extended
use extended regular expressions in the script.
-s, --separate
consider files as separate rather than as a single continuous
long stream.
-u, --unbuffered
load minimal amounts of data from the input files and flush
the output buffers more often
-z, --null-data
separate lines by NUL characters
--help
display this help and exit
--version
output version information and exit
If no -e, --expression, -f, or --file option is given, then the first
non-option argument is taken as the sed script to interpret. All
remaining arguments are names of input files; if no input files are
specified, then the standard input is read.
GNU sed home page: <http://www.gnu.org/software/sed/>.
General help using GNU software: <http://www.gnu.org/gethelp/>.
– -. ◔mkdir: invalid option -- '.'
Try 'mkdir --help' for more information.
/bin/repo-font-audit: line 388: cd: -.: invalid option
cd: usage: cd [-L|[-P [-e]] [-@]] [dir]
curl: (3) [globbing] bad range specification in column 90
◑rpm2cpio: *.rpm: No such file or directory
◕cat: invalid option -- '.'
Try 'cat --help' for more information.
cpio: premature end of archive
cat: invalid option -- '.'
Try 'cat --help' for more information.
touch: invalid option -- '.'
Try 'touch --help' for more information.
cat: invalid option -- '.'
Try 'cat --help' for more information.
cpio: premature end of archive
rm: invalid option -- '.'
Try 'rm ./-..cpio' to remove the file '-..cpio'.
Try 'rm --help' for more information.
● sed: invalid option -- '.'
Usage: sed [OPTION]... {script-only-if-no-other-script} [input-file]...
-n, --quiet, --silent
suppress automatic printing of pattern space
-e script, --expression=script
add the script to the commands to be executed
-f script-file, --file=script-file
add the contents of script-file to the commands to be executed
--follow-symlinks
follow symlinks when processing in place
-i[SUFFIX], --in-place[=SUFFIX]
edit files in place (makes backup if SUFFIX supplied)
-c, --copy
use copy instead of rename when shuffling files in -i mode
-b, --binary
does nothing; for compatibility with WIN32/CYGWIN/MSDOS/EMX (
open files in binary mode (CR+LFs are not treated specially))
-l N, --line-length=N
specify the desired line-wrap length for the `l' command
--posix
disable all GNU extensions.
-r, --regexp-extended
use extended regular expressions in the script.
-s, --separate
consider files as separate rather than as a single continuous
long stream.
-u, --unbuffered
load minimal amounts of data from the input files and flush
the output buffers more often
-z, --null-data
separate lines by NUL characters
--help
display this help and exit
--version
output version information and exit
If no -e, --expression, -f, or --file option is given, then the first
non-option argument is taken as the sed script to interpret. All
remaining arguments are names of input files; if no input files are
specified, then the standard input is read.
GNU sed home page: <http://www.gnu.org/software/sed/>.
General help using GNU software: <http://www.gnu.org/gethelp/>.
sed: invalid option -- '.'
Usage: sed [OPTION]... {script-only-if-no-other-script} [input-file]...
-n, --quiet, --silent
suppress automatic printing of pattern space
-e script, --expression=script
add the script to the commands to be executed
-f script-file, --file=script-file
add the contents of script-file to the commands to be executed
--follow-symlinks
follow symlinks when processing in place
-i[SUFFIX], --in-place[=SUFFIX]
edit files in place (makes backup if SUFFIX supplied)
-c, --copy
use copy instead of rename when shuffling files in -i mode
-b, --binary
does nothing; for compatibility with WIN32/CYGWIN/MSDOS/EMX (
open files in binary mode (CR+LFs are not treated specially))
-l N, --line-length=N
specify the desired line-wrap length for the `l' command
--posix
disable all GNU extensions.
-r, --regexp-extended
use extended regular expressions in the script.
-s, --separate
consider files as separate rather than as a single continuous
long stream.
-u, --unbuffered
load minimal amounts of data from the input files and flush
the output buffers more often
-z, --null-data
separate lines by NUL characters
--help
display this help and exit
--version
output version information and exit
If no -e, --expression, -f, or --file option is given, then the first
non-option argument is taken as the sed script to interpret. All
remaining arguments are names of input files; if no input files are
specified, then the standard input is read.
GNU sed home page: <http://www.gnu.org/software/sed/>.
General help using GNU software: <http://www.gnu.org/gethelp/>.
Analysing files…
♻
Consolidating data…
Conducting tests:
— Error: fonts deployed outside /usr/share/fonts
⇒ None!
— Error: fonts in packages that do not declare font metadata
⇒ None!
— Error: packages that mix different font families
⇒ None!
— Error: exact font duplication
⇒ None!
— Error: font faces duplicated by different packages
⇒ None!
— Error: fonts fc-query can not parse
⇒ None!
— Error: fonts not identified as such by libmagic
⇒ None!
— Error: broken symlinks to font files
⇒ None!
— Error: rpmlint
⇒ None!
— Error: fonts in packages that contain non-font data
⇒ None!
— Error: fonts in arch packages
⇒ None!
— Warning: fonts in packages that do not respect font naming conventions
⇒ None!
— Warning: bad font naming
⇒ None!
— Warning: core fonts use
⇒ None!
— Warning: font linking
⇒ None!
— Warning: font faces duplicated within a package
⇒ None!
— Warning: fonts that do not pass fontlint sanity checks
⇒ None!
— Warning: fonts with localized metadata but no English variant
⇒ None!
— Suggestion: fonts with partial script coverage
⇒ None!
— Suggestion: fonts with partial unicode block coverage
⇒ None!
Audit results:
– packages that declare font metadata:
⇒ None!
☛ File size is computed as extracted, while rpm is a compressed format.
☛ Mid-term, files in legacy PCF or Type1 formats need to be converted or
removed.
– font files in other packages (we should not find any!)
⇒ None!
– errors, warnings and suggestions:
⇒ None!
Packing mail data…
Packing result data…
Audit complete!
Run time: 9 s.
Number of items processed:
⇒ None!
1. Extracted data:
/home/kvolny/rpmbuild/RPMS/noarch/repo-font-audit-testrepo-20151014T175728Z.tar.xz
2. Short summary:
/home/kvolny/rpmbuild/RPMS/noarch/repo-font-audit-testrepo-20151014T175728Z-short.tar.xz
3. Mail data:
/home/kvolny/rpmbuild/RPMS/noarch/repo-font-audit-testrepo-20151014T175728Z-mail.tar.xz
This report was generated by the repo-font-audit command from:
http://fedoraproject.org/wiki/fontpackages
Please post questions, suggestions, patches or bug reports to:
https://admin.fedoraproject.org/mailman/listinfo/fonts
(subscription required)
♻
Expected results:
(no such errors)
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=5nIiUgzabR&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1376999
Bug ID: 1376999
Summary: comic-neue-fonts-2.3 is available
Product: Fedora
Version: rawhide
Component: comic-neue-fonts
Keywords: FutureFeature, Triaged
Assignee: kvolny(a)redhat.com
Reporter: upstream-release-monitoring(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org, kvolny(a)redhat.com
Latest upstream release: 2.3
Current version/release in rawhide: 2.2-3.fc24
URL: http://comicneue.com/
Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy
More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring
Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.
Based on the information from anitya:
https://release-monitoring.org/project/8250/
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=825115
Bug ID: 825115
QA Contact: extras-qa(a)fedoraproject.org
Severity: unspecified
Version: 16
Priority: unspecified
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, psatpute(a)redhat.com
Assignee: psatpute(a)redhat.com
Summary: [kn_IN] Lohit Kannada glyphs of consonants with vowel
signs -II, -EE, -OO and -AI should be optimized
Regression: ---
Story Points: ---
Classification: Fedora
OS: Unspecified
Reporter: samjnaa(a)gmail.com
Type: Bug
Documentation: ---
Hardware: Unspecified
Mount Type: ---
Status: NEW
Component: lohit-kannada-fonts
Product: Fedora
Description of problem:
Currently the Lohit Kannada fonts unnecessarily contain separate glyphs for
consonants with vowel signs -II, -EE, -OO and -AI. These are merely sequences
of other glyphs.
In the case of -II, -EE, -OO the glyphs are the same as those of the
corresponding short vowels plus a separate glyph 0CD5 Kannada Length Mark ೕ
(unlike in Telugu where the length mark ligates with the syllable). Therefore
instead of doing substitutions of:
CONSONANT + VOWEL_SIGN_II/EE/OO --> CONSONANT_VOWELSIGN_II/EE/OO
the optimized way would be to do:
CONSONANT + VOWEL_SIGN_II/EE/OO --> CONSONANT_VOWELSIGN_I/E/O LENGTH_MARK
If this is done, any changes that are reflected on the
CONSONANT_VOWELSIGN_I/E/O glyphs would automatically reflect for the long
vowels as well without additional work being needed. For instance, see my
recent report of bug 825104. If that bug is fixed for short vowels I, E and O,
automatically it would reflect for II, EE and OO also.
As for -AI, it is merely sequence of glyph for -E plus 0CD6 Kannada AI Length
Mark ೖ. So instead of doing substitutions of:
CONSONANT + VOWEL_SIGN_AI --> CONSONANT_VOWELSIGN_AI
the optimized way would be to do:
CONSONANT + VOWEL_SIGN_AI --> CONSONANT_VOWELSIGN_E AI_LENGTH_MARK
with same benefits as above.
Further, when handling combinations of:
CONSONANT1 + VIRAMA + CONSONANT2 + VOWEL_SIGN_II/EE/OO/AU
by separating the length mark as recommended here, the sub-base form of
CONSONANT2 can be placed closer to the base CONSONANT1 which is also
typographically a desirable factor in a good font. The rules would be:
CONSONANT1 + VIRAMA + CONSONANT2 + VOWEL_SIGN_II/EE/OO/AU -->
CONSONANT1_VOWEL_SIGN_I/E/O + SUB_BASE_CONSONANT_2 + (AI_)LENGTH_MARK
Version-Release number of selected component (if applicable):
2.5.1
How reproducible:
Examine the internals of Lohit Kannada font.
Actual results:
Currently there are separate glyphs for consonants with vowel signs -II, -EE,
-OO and -AI unnecessarily. These are merely sequences of other glyphs.
Therefore any change effected on the component glyphs has to be re-done here.
Expected results:
The superfluous glyphs should be removed and the appropriate effect should be
achieved by appropriate smartfont rules as indicated above.
Additional info:
This would also reduce the size of the font. Not an issue on laptops/desktops
but nowadays Lohit fonts are finding their way into smaller screens such as
smartphones, and it would be good to have a trim font with small footprint.
--
You are receiving this mail because:
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: [hi_IN][Dependent Vowels]Press backspace key it delete the whole char and letter before it
https://bugzilla.redhat.com/show_bug.cgi?id=500110
Summary: [hi_IN][Dependent Vowels]Press backspace key it delete
the whole char and letter before it
Product: Fedora
Version: 10
Platform: i386
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: pango
AssignedTo: besfahbo(a)redhat.com
ReportedBy: kxiong(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: besfahbo(a)redhat.com, fedora-fonts-bugs-list(a)redhat.com
Classification: Fedora
Target Release: ---
Description of problem:
In gedit press Backspace key to delete the whole char,it delete both the whole
char and the letter before it
Version-Release number of selected component (if applicable):
pango-devel-1.22.1-1.fc10.i386
pango-1.22.1-1.fc10.i386
pangomm-2.14.0-2.fc10.i386
How reproducible:
always
Steps to Reproduce:
1.In gedit input dabenा
2.Press Backspace key to delete the whole char ा
Actual results:
It delete the whole char and the letter n when pressing the Backspace key.
Expected results:
It should only delete the whole char.
Additional info:
1. U+093E ा
2. U+093F ि
3. U+0940 ी
4. U+0941 ु
5. U+0942 ू
6. U+0943 ृ
7. U+0944 ॄ
8. U+0945 ॅ
9. U+0946 ॆ
10. U+0947 े
11. U+0948 ै
12. U+0949 ॉ
13. U+094B ो
14. U+094C ौ
in Dependent Vowels all have the same problem
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Please rebuild using external Adobe CMap and AGLFN data
https://bugzilla.redhat.com/show_bug.cgi?id=525881
Summary: Please rebuild using external Adobe CMap and AGLFN
data
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: freetype
AssignedTo: besfahbo(a)redhat.com
ReportedBy: nicolas.mailhot(a)laposte.net
QAContact: extras-qa(a)fedoraproject.org
CC: besfahbo(a)redhat.com, kevin(a)tigcc.ticalc.org,
fedora-fonts-bugs-list(a)redhat.com
Blocks: 182235,473302
Classification: Fedora
Description of problem:
The Debian fonttool packager noticed a problem in fonttool's embedded Adobe
CMap and AGLFN data and got Adobe to release them under a good license
This data is embeded in many packages, including yours
Please rebuild your package using an external shared Adobe CMap and AGLFN data
package
FE-LEGAL since this was all triggered by a legal check Debian-side
See also
http://bonedaddy.net/pabs3/log/2009/09/24/adobe-data-freed/http://lwn.net/Articles/354360/http://opensource.adobe.com/wiki/display/cmap/CMap+Resources
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1332250
Bug ID: 1332250
Summary: Incorrect font configuration
Product: Fedora
Version: rawhide
Component: open-sans-fonts
Assignee: pvoborni(a)redhat.com
Reporter: dag.odenhall(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
pvoborni(a)redhat.com
When a website requests Open Sans, Firefox uses Comfortaa. I have both fonts
installed. I don't know if the following is the cause, because the matching
works correctly with fc-match, but I discovered this and it's still wrong, I
think.
The open-sans-fonts package includes this fontconfig rule:
<alias>
<family>Open Sans</family>
<prefer>
<family>sans-serif</family>
</prefer>
</alias>
In my understanding of fontconfig, this is saying "Edit the font family list
for Open Sans and prepend the sans-serif font family" i.e. Open Sans itself is
given *less* priority than all other sans-serif fonts. The
aajohan-comfortaa-fonts package includes this (correct) rule:
<alias>
<family>sans-serif</family>
<prefer>
<family>Comfortaa</family>
</prefer>
</alias>
And so perhaps C being early in the alphabet or perhaps because being the next
fontconfig file in my conf.d (I don't fully understand fontconfig) the combined
effect ends up being "When looking for Open Sans, the first match is sans-serif
which in turn is Comfortaa".
I think the Open Sans rule above should be edited to something closer to the
Comfortaa rule above, like:
<alias>
<family>sans-serif</family>
<prefer>
<family>Open Sans</family>
</prefer>
</alias>
The second rule it contains is also wrong, I think, and not like how any other
fonts are configured:
<alias>
<family>sans-serif</family>
<default>
<family>Open Sans</family>
</default>
</alias>
Should probably also swap the families like so:
<alias>
<family>Open Sans</family>
<default>
<family>sans-serif</family>
</default>
</alias>
This Firefox bug seems relevant but I think this is a bug in the packaged font
configuration and really unrelated to Firefox (I didn't read the whole bug):
https://bugzilla.mozilla.org/show_bug.cgi?id=1245811
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1321551
Bug ID: 1321551
Summary: RFE: Recommend some specific general purpose font
Product: Fedora
Version: rawhide
Component: fontconfig
Assignee: tagoh(a)redhat.com
Reporter: ville.skytta(a)iki.fi
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, pnemade(a)redhat.com,
tagoh(a)redhat.com
Currently fontconfig has a dependency on font(:lang=en). For minimal setups
where fontconfig is involved in that don't specify anything more specific than
that, it results in getting the first satisfying package by alphabetical sort
order to be installed. At the moment that is aajohan-comfortaa-fonts, which is
not a very good default, and could change based on what names of packages are
available.
Instead, I suggest adding (in addition to the existing hard dependency on
font(:lang=en)) a Recommends that would by default (with dnf) pull in something
that is a better default and already a default in common Fedora installations,
such as abattis-cantarell-fonts which AFAIK is the default for GNOME. Some
other potential candidates would be liberation-sans-fonts and
dejavu-sans-fonts. Not sure if Suggests would work for this purpose, or if it
needs to be Recommends.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1444911
Bug ID: 1444911
Summary: CVE-2017-7864 freetype: heap-based buffer overflow
related to the tt_size_reset function
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: medium
Priority: medium
Assignee: security-response-team(a)redhat.com
Reporter: amaris(a)redhat.com
CC: behdad(a)fedoraproject.org, bmcclain(a)redhat.com,
cfergeau(a)redhat.com, dblechte(a)redhat.com,
eedri(a)redhat.com, erik-fedora(a)vanpienbroek.nl,
fedora-mingw(a)lists.fedoraproject.org,
fonts-bugs(a)lists.fedoraproject.org, gklein(a)redhat.com,
kevin(a)tigcc.ticalc.org, lsurette(a)redhat.com,
mgoldboi(a)redhat.com, michal.skrivanek(a)redhat.com,
mkasik(a)redhat.com, rbalakri(a)redhat.com,
rh-spice-bugs(a)redhat.com, rjones(a)redhat.com,
sherold(a)redhat.com, srevivo(a)redhat.com,
ydary(a)redhat.com, ykaul(a)redhat.com
FreeType 2 before 2017-02-02 has an out-of-bounds write caused by a heap-based
buffer overflow related to the tt_size_reset function in truetype/ttobjs.c.
Bug report:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=509
Upstream patch:
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=e669959…
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1429965
Bug ID: 1429965
Summary: CVE-2016-10244 freetype: parse_charstrings function in
type1/t1load.c does not ensure that a font contains a
glyph name
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: medium
Priority: medium
Assignee: security-response-team(a)redhat.com
Reporter: anemec(a)redhat.com
CC: behdad(a)fedoraproject.org, bmcclain(a)redhat.com,
cfergeau(a)redhat.com, dblechte(a)redhat.com,
eedri(a)redhat.com, erik-fedora(a)vanpienbroek.nl,
fedora-mingw(a)lists.fedoraproject.org,
fonts-bugs(a)lists.fedoraproject.org, gklein(a)redhat.com,
kevin(a)tigcc.ticalc.org, lsurette(a)redhat.com,
mgoldboi(a)redhat.com, michal.skrivanek(a)redhat.com,
mkasik(a)redhat.com, rbalakri(a)redhat.com,
rh-spice-bugs(a)redhat.com, rjones(a)redhat.com,
sherold(a)redhat.com, srevivo(a)redhat.com,
ydary(a)redhat.com, ykaul(a)redhat.com
The parse_charstrings function in type1/t1load.c in FreeType 2 does not ensure
that a font contains a glyph name, which allows remote attackers to cause a
denial of service (heap-based buffer over-read) or possibly have unspecified
other impact via a crafted file.
References:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=36
Upstream patch:
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/src/type1/t1…
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1444904
Bug ID: 1444904
Summary: CVE-2017-7858 freetype: out-of-bounds write related to
the TT_Get_MM_Var and sfnt_init_face functions
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: medium
Priority: medium
Assignee: security-response-team(a)redhat.com
Reporter: amaris(a)redhat.com
CC: behdad(a)fedoraproject.org, bmcclain(a)redhat.com,
cfergeau(a)redhat.com, dblechte(a)redhat.com,
eedri(a)redhat.com, erik-fedora(a)vanpienbroek.nl,
fedora-mingw(a)lists.fedoraproject.org,
fonts-bugs(a)lists.fedoraproject.org, gklein(a)redhat.com,
kevin(a)tigcc.ticalc.org, lsurette(a)redhat.com,
mgoldboi(a)redhat.com, michal.skrivanek(a)redhat.com,
mkasik(a)redhat.com, rbalakri(a)redhat.com,
rh-spice-bugs(a)redhat.com, rjones(a)redhat.com,
sherold(a)redhat.com, srevivo(a)redhat.com,
ydary(a)redhat.com, ykaul(a)redhat.com
FreeType 2 before 2017-03-07 has an out-of-bounds write related to the
TT_Get_MM_Var function in truetype/ttgxvar.c and the sfnt_init_face function in
sfnt/sfobjs.c.
Bug report:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=738
Upstream patch:
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=7793097…
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1444898
Bug ID: 1444898
Summary: CVE-2017-7857 freetype: heap-based buffer overflow
related to the TT_Get_MM_Var function
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: medium
Priority: medium
Assignee: security-response-team(a)redhat.com
Reporter: amaris(a)redhat.com
CC: behdad(a)fedoraproject.org, bmcclain(a)redhat.com,
cfergeau(a)redhat.com, dblechte(a)redhat.com,
eedri(a)redhat.com, erik-fedora(a)vanpienbroek.nl,
fedora-mingw(a)lists.fedoraproject.org,
fonts-bugs(a)lists.fedoraproject.org, gklein(a)redhat.com,
kevin(a)tigcc.ticalc.org, lsurette(a)redhat.com,
mgoldboi(a)redhat.com, michal.skrivanek(a)redhat.com,
mkasik(a)redhat.com, rbalakri(a)redhat.com,
rh-spice-bugs(a)redhat.com, rjones(a)redhat.com,
sherold(a)redhat.com, srevivo(a)redhat.com,
ydary(a)redhat.com, ykaul(a)redhat.com
FreeType 2 before 2017-03-08 has an out-of-bounds write caused by a heap-based
buffer overflow related to the TT_Get_MM_Var function in truetype/ttgxvar.c and
the sfnt_init_face function in sfnt/sfobjs.c.
Bug report:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=759
Upstream patch:
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=7bbb91f…
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1444895
Bug ID: 1444895
Summary: CVE-2016-10328 freetype: heap-based buffer overflow
related to the cff_parser_run function
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: medium
Priority: medium
Assignee: security-response-team(a)redhat.com
Reporter: amaris(a)redhat.com
CC: behdad(a)fedoraproject.org, bmcclain(a)redhat.com,
cfergeau(a)redhat.com, dblechte(a)redhat.com,
eedri(a)redhat.com, erik-fedora(a)vanpienbroek.nl,
fedora-mingw(a)lists.fedoraproject.org,
fonts-bugs(a)lists.fedoraproject.org, gklein(a)redhat.com,
kevin(a)tigcc.ticalc.org, lsurette(a)redhat.com,
mgoldboi(a)redhat.com, michal.skrivanek(a)redhat.com,
mkasik(a)redhat.com, rbalakri(a)redhat.com,
rh-spice-bugs(a)redhat.com, rjones(a)redhat.com,
sherold(a)redhat.com, srevivo(a)redhat.com,
ydary(a)redhat.com, ykaul(a)redhat.com
FreeType 2 before 2016-12-16 has an out-of-bounds write caused by a heap-based
buffer overflow related to the cff_parser_run function in cff/cffparse.c.
Bug report:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=289
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1446500
Bug ID: 1446500
Summary: CVE-2017-8105 freetype: heap-based buffer overflow
related to the t1_decoder_parse_charstrings
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: medium
Priority: medium
Assignee: security-response-team(a)redhat.com
Reporter: amaris(a)redhat.com
CC: behdad(a)fedoraproject.org, bmcclain(a)redhat.com,
cfergeau(a)redhat.com, dblechte(a)redhat.com,
eedri(a)redhat.com, erik-fedora(a)vanpienbroek.nl,
fedora-mingw(a)lists.fedoraproject.org,
fonts-bugs(a)lists.fedoraproject.org, gklein(a)redhat.com,
kevin(a)tigcc.ticalc.org, lsurette(a)redhat.com,
mgoldboi(a)redhat.com, michal.skrivanek(a)redhat.com,
mkasik(a)redhat.com, rbalakri(a)redhat.com,
rh-spice-bugs(a)redhat.com, rjones(a)redhat.com,
sherold(a)redhat.com, srevivo(a)redhat.com,
ydary(a)redhat.com, ykaul(a)redhat.com
FreeType 2 before 2017-03-24 has an out-of-bounds write caused by a heap-based
buffer overflow related to the t1_decoder_parse_charstrings function in
psaux/t1decode.c.
Bug report:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=935
Upstream patch:
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=f958c48…
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1271620
Bug ID: 1271620
Summary: please update spec templates as per latest guidelines
Product: Fedora
Version: 23
Component: fontpackages
Assignee: nicolas.mailhot(a)laposte.net
Reporter: kvolny(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
nicolas.mailhot(a)laposte.net, paul(a)frixxon.co.uk,
tagoh(a)redhat.com
Description of problem:
I'm trying to package a font. While filing the spec template, I have found that
there is:
%install
rm -fr %{buildroot}
but the buildroot is now cleaned automatically so the `rm` command should not
be present.
Please update the spec templates according to the latest guidelines. Also note
that there may be other deviations from current packaging guidelines that I
have overlooked ...
Version-Release number of selected component (if applicable):
fontpackages-devel-1.44-14.fc23.noarch
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=162cGuTqJk&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1400602
Bug ID: 1400602
Summary: stix-fonts-2.0.0 is available
Product: Fedora
Version: rawhide
Component: stix-fonts
Keywords: FutureFeature, Triaged
Assignee: nicolas.mailhot(a)laposte.net
Reporter: upstream-release-monitoring(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
nicolas.mailhot(a)laposte.net, paul(a)frixxon.co.uk
Latest upstream release: 2.0.0
Current version/release in rawhide: 1.1.0-9.fc24
URL: http://sourceforge.net/projects/stixfonts
Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy
More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring
Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.
Based on the information from anitya:
https://release-monitoring.org/project/4893/
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1474257
Bug ID: 1474257
Summary: fc-cache in multilib does not create 32bit cache files
Product: Fedora
Version: rawhide
Component: fontconfig
Assignee: tagoh(a)redhat.com
Reporter: tagoh(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, pnemade(a)redhat.com,
tagoh(a)redhat.com
Blocks: 1468978
Description of problem:
On 64bit env, there are no way to generate {be,le}32d{4,8} caches unless
removing 64bit version of packages because the 32bit version of fc-cache binary
is hidden by the package manager. need to have separate binary to address like
gtk does.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1468978
[Bug 1468978] fc-cache in multilib does not create 32bit cache files
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1450802
Bug ID: 1450802
Summary: @sinhala-suppport group: please change the default
font from LKLUG to Noto
Product: Fedora
Version: 25
Component: google-noto-fonts
Severity: low
Assignee: psatpute(a)redhat.com
Reporter: harshula(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
psatpute(a)redhat.com, pwu(a)redhat.com
[This BZ should be filed against the @sinhala-support group.]
Description of problem:
Please change the default font from LKLUG to Noto for the Sinhala script.
The LKLUG font is viewed as deprecated and we've been trying to
encourage other fonts that can succeed as the default Sinhala font on
GNU/Linux.
At this stage the Noto Sinhala range, in fonts-noto-hinted, is a more
appropriate default font than LKLUG.
See the discussion here:
http://sourceforge.net/p/sinhala/mailman/message/34481529/
See Debian Bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837969
Thanks,
#
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1485789
Bug ID: 1485789
Summary: bogus permissions on /usr/share/doc/urw-fonts
Product: Fedora
Version: 26
Component: urw-fonts
Assignee: dkaspar(a)redhat.com
Reporter: rc040203(a)freenet.de
QA Contact: extras-qa(a)fedoraproject.org
CC: dkaspar(a)redhat.com,
fonts-bugs(a)lists.fedoraproject.org, than(a)redhat.com
Description of problem:
The urw-fonts package's permission on /usr/share/doc/urw-fonts are set
read-only:
$ rpm -qlv urw-fonts | grep doc
drw-r--r-- 2 root root 0 Feb 12 2017
/usr/share/doc/urw-fonts
-rw-r--r-- 1 root root 17992 Apr 23 2001
/usr/share/doc/urw-fonts/COPYING
-rw-r--r-- 1 root root 2245 Jan 18 2002
/usr/share/doc/urw-fonts/README
-rw-r--r-- 1 root root 1317 Jul 12 2002
/usr/share/doc/urw-fonts/README.tweaks
Version-Release number of selected component (if applicable):
urw-fonts-2.4-23.fc26.noarch
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1504381
Bug ID: 1504381
Summary: libXfont-1.5.3 is available
Product: Fedora
Version: rawhide
Component: libXfont
Keywords: FutureFeature, Triaged
Assignee: btissoir(a)redhat.com
Reporter: upstream-release-monitoring(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: ajax(a)redhat.com, alexl(a)redhat.com,
btissoir(a)redhat.com, caillon+fedoraproject(a)gmail.com,
caolanm(a)redhat.com,
fonts-bugs(a)lists.fedoraproject.org,
jglisse(a)redhat.com, john.j5live(a)gmail.com,
mbarnes(a)fastmail.com, rhughes(a)redhat.com,
rstrode(a)redhat.com, sandmann(a)redhat.com
Latest upstream release: 1.5.3
Current version/release in rawhide: 1.5.2-5.fc28
URL: http://xorg.freedesktop.org/archive/individual/lib/
Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy
More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring
Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.
Based on the information from anitya:
https://release-monitoring.org/project/1776/
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1500693
Bug ID: 1500693
Summary: CVE-2017-13722 libXfont: Insufficient input validation
in pcfread.c
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: low
Priority: low
Assignee: security-response-team(a)redhat.com
Reporter: anemec(a)redhat.com
CC: ajax(a)redhat.com, alexl(a)redhat.com,
btissoir(a)redhat.com, caillon+fedoraproject(a)gmail.com,
caolanm(a)redhat.com,
fonts-bugs(a)lists.fedoraproject.org,
jglisse(a)redhat.com, john.j5live(a)gmail.com,
mbarnes(a)fastmail.com, rhughes(a)redhat.com,
rstrode(a)redhat.com, sandmann(a)redhat.com
It was discovered that libXfont incorrectly handled certain malformed PCF
files. A local attacker could use this issue to cause libXfont to crash,
resulting in a denial of service, or possibly obtain sensitive information.
Upstream patch:
https://cgit.freedesktop.org/xorg/lib/libXfont/commit/?id=672bb944311392e24…
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1500690
Bug ID: 1500690
Summary: CVE-2017-13720 libXfont: Insufficient input validation
in fontdir.c
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: low
Priority: low
Assignee: security-response-team(a)redhat.com
Reporter: anemec(a)redhat.com
CC: ajax(a)redhat.com, alexl(a)redhat.com,
btissoir(a)redhat.com, caillon+fedoraproject(a)gmail.com,
caolanm(a)redhat.com,
fonts-bugs(a)lists.fedoraproject.org,
jglisse(a)redhat.com, john.j5live(a)gmail.com,
mbarnes(a)fastmail.com, rhughes(a)redhat.com,
rstrode(a)redhat.com, sandmann(a)redhat.com
It was discovered that libXfont incorrectly handled certain patterns in
PatternMatch. A local attacker could use this issue to cause libXfont to
crash, resulting in a denial of service, or possibly obtain sensitive
information.
Upstream patch:
https://cgit.freedesktop.org/xorg/lib/libXfont/commit/?id=d1e670a4a8704b870…
--
You are receiving this mail because:
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: [as_IN] [Codepoint- Additional Vowels] U+09E2 has error.
https://bugzilla.redhat.com/show_bug.cgi?id=499358
Summary: [as_IN] [Codepoint- Additional Vowels] U+09E2 has
error.
Product: Fedora
Version: 10
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: pango
AssignedTo: besfahbo(a)redhat.com
ReportedBy: xinsun(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: besfahbo(a)redhat.com, fedora-fonts-bugs-list(a)redhat.com
Classification: Fedora
Target Release: ---
Description of problem:
Input "09E2" with "RAW CODE" in gedit, the word has error.
Version-Release number of selected component (if applicable):
pangomm-2.14.1-1.fc10.x86_64
pango-1.22.3-1.fc10.i386
pango-1.22.3-1.fc10.x86_64
pango-devel-1.22.3-1.fc10.x86_64
How reproducible:
Steps to Reproduce:
1.Select "RAW CODE" in scim-bridge.
2.Input "09E2" in gedit.
Actual results:
The result is ৢ and is different from the URL
http://batman.bne.redhat.com/~indic/IndicTC/lang/as_IN/font/image/09E2.jpg
Expected results:
The word is same with the URL
http://batman.bne.redhat.com/~indic/IndicTC/lang/as_IN/font/image/09E2.jpg
Additional info:
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1475398
Bug ID: 1475398
Summary: CVE-2017-11568 CVE-2017-11569 CVE-2017-11570
CVE-2017-11571 CVE-2017-11572 CVE-2017-11573
CVE-2017-11574 CVE-2017-11575 CVE-2017-11576
CVE-2017-11577 fontforge: various flaws [fedora-all]
Product: Fedora
Version: 26
Component: fontforge
Keywords: Security, SecurityTracking
Severity: low
Priority: low
Assignee: kevin(a)scrye.com
Reporter: anemec(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org, kevin(a)scrye.com,
paul(a)frixxon.co.uk, pnemade(a)redhat.com
This is an automatically created tracking bug! It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of fedora-all.
For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.
For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs
When submitting as an update, use the fedpkg template provided in the next
comment(s). This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.
Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg commit message.
NOTE: this issue affects multiple supported versions of Fedora. While only
one tracking bug has been filed, please correct all affected versions at
the same time. If you need to fix the versions independent of each other,
you may clone this bug as appropriate.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1475397
Bug ID: 1475397
Summary: CVE-2017-11577 fontforge: Buffer over-read in getsid
function
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: low
Priority: low
Assignee: security-response-team(a)redhat.com
Reporter: anemec(a)redhat.com
CC: eng-i18n-bugs(a)redhat.com,
fonts-bugs(a)lists.fedoraproject.org, kevin(a)scrye.com,
paul(a)frixxon.co.uk, pnemade(a)redhat.com
FontForge 20161012 is vulnerable to a buffer over-read in getsid (parsettf.c)
resulting in DoS or via a crafted otf file.
Upstream issue:
https://github.com/fontforge/fontforge/issues/3088
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1475396
Bug ID: 1475396
Summary: CVE-2017-11576 fontforge: Does not ensure a positive
size in a weight vector memcpy call in readcfftopdict
function
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: low
Priority: low
Assignee: security-response-team(a)redhat.com
Reporter: anemec(a)redhat.com
CC: eng-i18n-bugs(a)redhat.com,
fonts-bugs(a)lists.fedoraproject.org, kevin(a)scrye.com,
paul(a)frixxon.co.uk, pnemade(a)redhat.com
FontForge 20161012 does not ensure a positive size in a weight vector memcpy
call in readcfftopdict (parsettf.c) resulting in DoS via a crafted otf file.
Upstream issue:
https://github.com/fontforge/fontforge/issues/3091
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1475393
Bug ID: 1475393
Summary: CVE-2017-11575 fontforge: Buffer over-read in
strnmatch function
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: low
Priority: low
Assignee: security-response-team(a)redhat.com
Reporter: anemec(a)redhat.com
CC: eng-i18n-bugs(a)redhat.com,
fonts-bugs(a)lists.fedoraproject.org, kevin(a)scrye.com,
paul(a)frixxon.co.uk, pnemade(a)redhat.com
FontForge 20161012 is vulnerable to a buffer over-read in strnmatch (char.c)
resulting in DoS or via a crafted otf file, related to a call from the
readttfcopyrights function in parsettf.c.
Upstream issue:
https://github.com/fontforge/fontforge/issues/3096
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1475392
Bug ID: 1475392
Summary: CVE-2017-11574 fontforge: Heap-based buffer overflow
in readcffset function
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: low
Priority: low
Assignee: security-response-team(a)redhat.com
Reporter: anemec(a)redhat.com
CC: eng-i18n-bugs(a)redhat.com,
fonts-bugs(a)lists.fedoraproject.org, kevin(a)scrye.com,
paul(a)frixxon.co.uk, pnemade(a)redhat.com
FontForge 20161012 is vulnerable to a heap-based buffer overflow in readcffset
(parsettf.c) resulting in DoS via a crafted otf file.
Upstream issue:
https://github.com/fontforge/fontforge/issues/3090
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1475391
Bug ID: 1475391
Summary: CVE-2017-11573 fontforge: Buffer over-read in
ValidatePostScriptFontName function
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: low
Priority: low
Assignee: security-response-team(a)redhat.com
Reporter: anemec(a)redhat.com
CC: eng-i18n-bugs(a)redhat.com,
fonts-bugs(a)lists.fedoraproject.org, kevin(a)scrye.com,
paul(a)frixxon.co.uk, pnemade(a)redhat.com
FontForge 20161012 is vulnerable to a buffer over-read in
ValidatePostScriptFontName (parsettf.c) resulting in DoS via a crafted otf
file.
Upstream issue:
https://github.com/fontforge/fontforge/issues/3098
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1475390
Bug ID: 1475390
Summary: CVE-2017-11572 fontforge: Heap-based buffer over-read
in readcfftopidcts function
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: low
Priority: low
Assignee: security-response-team(a)redhat.com
Reporter: anemec(a)redhat.com
CC: eng-i18n-bugs(a)redhat.com,
fonts-bugs(a)lists.fedoraproject.org, kevin(a)scrye.com,
paul(a)frixxon.co.uk, pnemade(a)redhat.com
FontForge 20161012 is vulnerable to a heap-based buffer over-read in
readcfftopdicts (parsettf.c) resulting in DoS via a crafted otf file.
Upstream issue:
https://github.com/fontforge/fontforge/issues/3092
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1475389
Bug ID: 1475389
Summary: CVE-2017-11571 fontforge: Stack-buffer overflow in
addnibble function
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: low
Priority: low
Assignee: security-response-team(a)redhat.com
Reporter: anemec(a)redhat.com
CC: eng-i18n-bugs(a)redhat.com,
fonts-bugs(a)lists.fedoraproject.org, kevin(a)scrye.com,
paul(a)frixxon.co.uk, pnemade(a)redhat.com
FontForge 20161012 is vulnerable to a stack-based buffer overflow in addnibble
(parsettf.c) resulting in DoS via a crafted otf file.
Upstream issue:
https://github.com/fontforge/fontforge/issues/3087
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1475388
Bug ID: 1475388
Summary: CVE-2017-11570 fontforge: Buffer over-read in umodenc
function
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: low
Priority: low
Assignee: security-response-team(a)redhat.com
Reporter: anemec(a)redhat.com
CC: eng-i18n-bugs(a)redhat.com,
fonts-bugs(a)lists.fedoraproject.org, kevin(a)scrye.com,
paul(a)frixxon.co.uk, pnemade(a)redhat.com
FontForge 20161012 is vulnerable to a buffer over-read in umodenc (parsettf.c)
resulting in DoS or via a crafted otf file.
Upstream issue:
https://github.com/fontforge/fontforge/issues/3097
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1475386
Bug ID: 1475386
Summary: CVE-2017-11569 fontforge: Heap-buffer over-read in
readttfcopyrights function
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: low
Priority: low
Assignee: security-response-team(a)redhat.com
Reporter: anemec(a)redhat.com
CC: eng-i18n-bugs(a)redhat.com,
fonts-bugs(a)lists.fedoraproject.org, kevin(a)scrye.com,
paul(a)frixxon.co.uk, pnemade(a)redhat.com
FontForge 20161012 is vulnerable to a heap-based buffer over-read in
readttfcopyrights (parsettf.c) resulting in DoS via a crafted otf file.
Upstream issue:
https://github.com/fontforge/fontforge/issues/3093
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1433628
Bug ID: 1433628
Summary: First line of pixels chopped off in Chromium/Chrome
when liberation-fonts built with fontforge > 20150430
Product: Fedora
Version: 25
Component: liberation-fonts
Assignee: psatpute(a)redhat.com
Reporter: chillermillerlong(a)hotmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com
Description of problem:
The current liberation-fonts package is built by fontforge 20160404 and results
in the top of the fonts being chopped off in some pages in Chrome/Chromium.
For example, with this page:
https://www.reddit.com/r/linux/comments/600h4f/wine_24_released/
When built with fontforge 20160404: http://i.imgur.com/kO2H3Hw.png
When built with fontforge 20150430: http://i.imgur.com/IQmu5o3.png
Notice how the first line of pixels is getting chopped off.
Version-Release number of selected component (if applicable):
liberation-fonts-common-1.07.4-7.fc24.noarch
liberation-mono-fonts-1.07.4-7.fc24.noarch
liberation-sans-fonts-1.07.4-7.fc24.noarch
liberation-serif-fonts-1.07.4-7.fc24.noarch
fontforge-20160404-5.fc25.x86_64
Additional info:
I did a git bisect and found that this is the commit in fontforge that
introduced the issue.
---
[chenxiaolong@cxl-fedora25vm fontforge]$ git bisect bad
e870019c2602d50eb00793e979f3e11bcc71d6cf is the first bad commit
commit e870019c2602d50eb00793e979f3e11bcc71d6cf
Author: Frédéric Wang <fred.wang(a)free.fr>
Date: Wed May 13 08:03:13 2015 +0200
Fix read/write of bits USE_TYPO_METRICS and WWS for OS2 version < 4
:040000 040000 7032ea971c1d084ab8a038b4a80d9092e53a8519
eb11e4b5a69718ad94d8dbfc414e7b2a944548d3 M fontforge
---
https://github.com/fontforge/fontforge/commit/e870019c2602d50eb00793e979f3e…
Is this something that can be fixed without affecting/breaking other fonts?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1414319
Bug ID: 1414319
Summary: freetype ftoption.h evaluates undefined macros
Product: Fedora
Version: 25
Component: freetype
Severity: low
Assignee: mkasik(a)redhat.com
Reporter: yeti(a)physics.muni.cz
QA Contact: extras-qa(a)fedoraproject.org
CC: behdad(a)fedoraproject.org,
fonts-bugs(a)lists.fedoraproject.org,
kevin(a)tigcc.ticalc.org, mkasik(a)redhat.com
Description of problem:
Header file /usr/include/freetype2/freetype/config/ftoption.h evaluates the
numerical value of undefined macro TT_CONFIG_OPTION_SUBPIXEL_HINTING. This is
somewhat annoying with -Wundef (and a poor practice).
Version-Release number of selected component (if applicable):
freetype-2.6.5-1.fc25
How reproducible:
Always.
Steps to Reproduce:
1. Create file bug.c with the following contents:
#include <ft2build.h>
#include FT_FREETYPE_H
2. Run (with freetype-devel installed)
gcc -Wundef -c $(pkg-config --cflags freetype2) bug.c
Actual results:
In file included from
/usr/include/freetype2/freetype/config/ftconfig-64.h:42:0,
from /usr/include/freetype2/freetype/config/ftconfig.h:9,
from /usr/include/freetype2/freetype/freetype.h:33,
from bug.c:2:
/usr/include/freetype2/freetype/config/ftoption.h:845:5: warning:
"TT_CONFIG_OPTION_SUBPIXEL_HINTING" is not defined [-Wundef]
#if TT_CONFIG_OPTION_SUBPIXEL_HINTING & 1
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/freetype2/freetype/config/ftoption.h:849:5: warning:
"TT_CONFIG_OPTION_SUBPIXEL_HINTING" is not defined [-Wundef]
#if TT_CONFIG_OPTION_SUBPIXEL_HINTING & 2
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Expected results:
It compiles cleanly.
Additional info:
The numerical evaluation should be guarded by an #ifdef -- AFAICT the expected
behaviour when TT_CONFIG_OPTION_SUBPIXEL_HINTING is undefined is that neither
TT_SUPPORT_SUBPIXEL_HINTING_INFINALITY nor TT_SUPPORT_SUBPIXEL_HINTING_MINIMAL
should be defined:
--- ftoption.h.orig 2017-01-18 10:41:32.517812687 +0100
+++ ftoption.h 2017-01-18 10:42:16.852136325 +0100
@@ -842,6 +842,7 @@
#ifdef TT_CONFIG_OPTION_BYTECODE_INTERPRETER
#define TT_USE_BYTECODE_INTERPRETER
+#ifdef TT_CONFIG_OPTION_SUBPIXEL_HINTING
#if TT_CONFIG_OPTION_SUBPIXEL_HINTING & 1
#define TT_SUPPORT_SUBPIXEL_HINTING_INFINALITY
#endif
@@ -850,6 +851,7 @@
#define TT_SUPPORT_SUBPIXEL_HINTING_MINIMAL
#endif
#endif
+#endif
/*
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1389683
Bug ID: 1389683
Summary: Blurred rendering
Product: Fedora
Version: 25
Component: freetype
Assignee: mkasik(a)redhat.com
Reporter: fedora(a)famillecollet.com
QA Contact: extras-qa(a)fedoraproject.org
CC: behdad(a)fedoraproject.org,
fonts-bugs(a)lists.fedoraproject.org,
kevin(a)tigcc.ticalc.org, mkasik(a)redhat.com
Created attachment 1214870
--> https://bugzilla.redhat.com/attachment.cgi?id=1214870&action=edit
Zoomed screen shot
Description of problem:
Since update to F25, font are blurred.
Version-Release number of selected component (if applicable):
freetype-2.6.5-1.fc25.x86_64
How reproducible:
Always
Notice: with F24, I solved the problem switching from Cantarell to Liberation,
but no success on F25.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1351287
Bug ID: 1351287
Summary: Wrong placement of polish glyph Ogonek
Product: Fedora
Version: rawhide
Component: liberation-fonts
Assignee: psatpute(a)redhat.com
Reporter: riemersebastian(a)hotmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com
Description of problem:
The following text when using font "LiberationSans-Regular" renders the polish
Ogonek far to the right which does not seem correct when compared to other
fonts.
INPUT: "Lektura dla pocza̜tkuja̜cych"
Version-Release number of selected component (if applicable):
version 2.0.0 (Downloaded from
https://www.fontsquirrel.com/fonts/liberation-sans)
How reproducible:
Just use the text "Lektura dla pocza̜tkuja̜cych" and the problem should be
visible (and see below)
Steps to Reproduce:
1. Go to https://www.fontsquirrel.com/fonts/liberation-sans
2. Go to tab "Test drive"
3. Enter text "Lektura dla pocza̜tkuja̜cych"
Actual results:
The result shows the Ogonek way to the right and AFAIK it should render
centered below the letter 'a'.
Expected results:
Compare by same steps as above, but e.g. choose as font: Junicode
(https://www.fontsquirrel.com/fonts/Junicode)
Additional info:
None
--
You are receiving this mail because:
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: fonts.alias refer to encodings not listed in fonts.dir
https://bugzilla.redhat.com/show_bug.cgi?id=733106
Summary: fonts.alias refer to encodings not listed in fonts.dir
Product: Fedora
Version: rawhide
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Severity: unspecified
Priority: unspecified
Component: sazanami-fonts
AssignedTo: tagoh(a)redhat.com
ReportedBy: viy(a)altlinux.org
QAContact: extras-qa(a)fedoraproject.org
CC: tagoh(a)redhat.com, fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org
Classification: Fedora
Story Points: ---
Type: ---
fonts.alias files refer to jisx020*.19??-0 font encodings while fonts.dir does
not list them.
looks like a fonts.scale/fonts.dir generation bug.
/usr/share/X11/fonts/encodings/large/*
encodings should be present during fonts.scale/fonts.dir generation.
sazanami-fonts-0.20040629-15.fc15.src.rpm
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1359716
Bug ID: 1359716
Summary: Please upgrade DejaVu to version 2.36
Product: Fedora
Version: rawhide
Component: dejavu-fonts
Assignee: nicolas.mailhot(a)laposte.net
Reporter: fred.wang(a)free.fr
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
nicolas.mailhot(a)laposte.net, paul(a)frixxon.co.uk,
peter(a)thecodergeek.com, smaitra(a)redhat.com
Dear Fedora Maintainers,
A new version of DejaVu has been released yesterday, please consider upgrading
the Fedora package to 2.36:
https://sourceforge.net/p/dejavu/mailman/message/35221644/
Note that in particular it includes a new math font.
PS: I also sent an email on
https://lists.fedoraproject.org/archives/list/fonts@lists.fedoraproject.org…
but without any replies so far. The new fonts are now already in Debian and
Ubuntu.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=825081
Bug ID: 825081
QA Contact: extras-qa(a)fedoraproject.org
Severity: unspecified
Version: 16
Priority: unspecified
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, psatpute(a)redhat.com
Assignee: psatpute(a)redhat.com
Summary: Lohit Kannada font does not properly handle vowel
signs in consonant clusters
Regression: ---
Story Points: ---
Classification: Fedora
OS: Unspecified
Reporter: samjnaa(a)gmail.com
Type: Bug
Documentation: ---
Hardware: Unspecified
Mount Type: ---
Status: NEW
Component: lohit-kannada-fonts
Product: Fedora
Created attachment 586752
--> https://bugzilla.redhat.com/attachment.cgi?id=586752&action=edit
ODT and PDF for test-case
Description of problem:
This seems to be a resurfacing of bug #223971 but since I saw no way to reopen
that bug (sorry if I'm wrong) I'm reporting this again.
Version-Release number of selected component (if applicable):
2.5.1
How reproducible:
In a word processor, select Lohit Kannada font and input Kannada Unicode
sequences having consonant clusters of the format CCV. I have attached a sample
ODT.
Actual results:
Except in a few cases of "popular" consonant clusters like K.SSA ಕ್ಷ and J.NYA
ಜ್ಞ, the vowel signs are not attached properly.
When the same text is rendered with other fonts (like Tunga of Microsoft even
loaded into Linux's LibreOffice) the sequences are shown properly without
overlaps or malformed glyphs.
Expected results:
The Kannada language uses lots of Sanskrit-based words and hence has many
consonant clusters with two and even three consonants. Also, when English words
are transliterated in Kannada script like ಎಕ್ಸ್ಪ್ಲೋರ್ (explore) etc for
sign-boards etc, even more consonant clusters will occur. In all these cases
Lohit Kannada should be able to gracefully handle such consonant clusters and
not output overlapping or malformed glyphs.
Additional info:
I have attached an ODT and PDF file demonstrating the problem.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=827516
Bug ID: 827516
QA Contact: extras-qa(a)fedoraproject.org
Severity: unspecified
Version: 16
Priority: unspecified
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, psatpute(a)redhat.com
Assignee: psatpute(a)redhat.com
Summary: [kn_IN] Vowel Signs U and UU do not correctly attach
to many consonants in Lohit Kannada
Regression: ---
Story Points: ---
Classification: Fedora
OS: Unspecified
Reporter: samjnaa(a)gmail.com
Type: Bug
Documentation: ---
Hardware: Unspecified
Mount Type: ---
Status: NEW
Component: lohit-kannada-fonts
Product: Fedora
Created attachment 588536
--> https://bugzilla.redhat.com/attachment.cgi?id=588536&action=edit
ODT and PDF for test-case
Description of problem:
While most other CONSONANT + VOWEL SIGN combinations in Lohit Kannada are
mapped to precomposed glyphs, there are no pre-composed glyphs for vowel signs
U and UU except for the consonants PA, PHA and VA (where the stroke for U/UU
needs to come from below the consonant rather than the normal right side of the
consonant).
While in most cases, by virtue of appropriate RSB and LSB values of the
consonant glyph and vowel sign glyph, the simple sequence of the two glyphs
creates an appropriate appearance, this leaves out several instances where the
glyphs do not overlap at all and hence appear disjointed. For a professional
appearance of the font, this should be fixed.
Version-Release number of selected component (if applicable):
2.5.1
How reproducible:
Input all possible sequences of Kannada consonants with vowel signs U and UU.
(See attached ODT for text. Use BabelMap
[http://www.babelstone.co.uk/software/babelmap.html] if you want the
codepoints.)
Actual results:
You can see (as in the attached PDF) that some consonants do not properly get
attached to the vowel signs U and UU.
Expected results:
All consonants should properly get attached to the vowel signs U and UU.
Additional info:
Consonants which are not properly joined with vowel sign U:
KA* NYA DDA DA BA RA SSA** RRA LLLA***
* = see at high magnification
** = may need separate precomposed glyph with some adjustment to shape of left
side of vowel sign
*** = so-called FA of Kannada Unicode
Consonants which are not properly joined with vowel sign UU:
Those already listed above for U, plus GHA and LLA, due to the shorter height
of the left-side ending node of this vowel sign.
I think in most cases appropriate kerning should solve the problem, except for
SSA + -U/-UU, GHA + -UU and LLA + -UU where separate glyphs would be advisable.
It is curious to note that DDA DA and BA are all disjointed whereas their
aspirated counterparts DDHA DHA and BHA which all have only an additional
notch-like stroke at the bottom are correctly joined with the vowel sign. I
think the LSB RSB values are carelessly allotted in some cases, unfortunately.
Other problems:
CU JU -- the pointed part on the left of the vowel sign U passes through the
consonants and comes out above (see carefully) -- actually *negative* kerning
is needed here so that the pointed part should only enter the consonant and not
again exit it.
(It seems this problem does not occur for vowel sign UU due to the shorter
height of the left-side ending node of this vowel sign which causes a problem
with GHA and LLA instead -- see above!)
Note:
Unfortunately I will not be able to provide a TTF patch for this as I am
already short of time on my official projects. Please take care of it. Thank
you!
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=839303
Bug ID: 839303
QA Contact: extras-qa(a)fedoraproject.org
Severity: unspecified
Version: rawhide
Priority: unspecified
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, psatpute(a)redhat.com
Assignee: psatpute(a)redhat.com
Summary: [ta_IN] Submission of glyphs for Tamil
fractions/symbols to be included in the Lohit Tamil
fonts
Regression: ---
Story Points: ---
Classification: Fedora
OS: Unspecified
Reporter: samjnaa(a)gmail.com
Type: Bug
Documentation: ---
Hardware: Unspecified
Mount Type: ---
Status: NEW
Component: lohit-tamil-fonts
Product: Fedora
Created attachment 597580
--> https://bugzilla.redhat.com/attachment.cgi?id=597580&action=edit
Lohit Tamil, Lohit Tamil Classical and Lohit Tamil Chart fonts with new
characters
Contributing new Tamil glyphs to Lohit Tamil family:
----------------------------------------------------
I have prepared a proposal to encode 62 characters for old Tamil fractions and
symbols to be encoded in Unicode. Seven of these are being proposed for the
Tamil BMP block and rest for a new Tamil Supplement block in the SMP.
For the glyphs required for the code chart I have largely devised new glyphs
based on existing Lohit Tamil glyphs under the derivative rights granted by the
OFL. Some glyphs which could not be derived, I created myself using Inkscape
and other tools.
I would like to donate all these glyphs to the Lohit project under the OFL for
eventual inclusion into the Lohit Tamil/Tamil Classical fonts. For now they may
be included in the PUA of an unofficial fork of the Lohit Tamil fonts. When
they are eventually encoded in Unicode, they may be officially mapped to the
new codepoints and included in the official distribution of the Lohit
Tamil/Tamil Classical fonts.
Using Lohit Tamil glyphs for Unicode code chart:
------------------------------------------------
In the proposal, I am also requesting the Unicode / ISO 10646 project editors
to use the Lohit Tamil font for the Unicode Tamil code charts (Tamil block, and
newly proposed Tamil Supplement block) because:
1) When the new characters are encoded and my glyphs used for the code chart,
it would look good to maintain stylistic uniformity in the code chart, and my
designed glyphs are stylistically like the Lohit Tamil glyphs as they are
mostly derived from them. So it would be good to use Lohit Tamil glyphs
throughout.
2) There are currently 72 Tamil characters in Unicode 6.1.0. The present
proposal almost doubles the number with 62 new characters. It would be a
significant and unnecessary effort for anyone else to duplicate my glyph design
work for so many characters to keep in with the current Tamil code chart font
style. So switching to Lohit Tamil for all glyphs is easier and advisable.
3) Personally I think the glyphs of Lohit Tamil are much "cleaner" than the
existing Tamil code chart font, and more representative of the nature and
beauty of the Tamil script.
4) The OFL already permits the use of the Lohit Tamil font (and its
derivatives) for any purpose, so there are (hopefully) no legal issues
pertaining which need to be cleared between Unicode and Red Hat (but of course,
IANAL).
I also sincerely request the cooperation of the Lohit / Fedora / Red Hat people
in permitting the Lohit Tamil glyphs to be used for the Unicode Tamil code
charts (i.e. for two blocks).
Fonts with new glyphs:
----------------------
I attach herewith a ZIP file containing three font files:
1) Lohit Tamil font, with newly proposed character glyphs mapped to the PUA.
2) Lohit Tamil Classical font, likewise.
3) Lohit Tamil Chart font, containing only glyphs required for the code chart
(for existing and new characters, totalling 134 in number, across two blocks
Tamil and Tamil Supplement) mapped to the existing and proposed characters for
convenience of Unicode / ISO 10646 editors.
Behaviour of new characters and requirement from the fonts' side:
-----------------------------------------------------------------
None of the newly proposed characters are combining characters in the sense of
combining marks. However, most of them are proposed for a new SMP Tamil block
and care might need to be taken for proper mapping so that on all platforms the
SMP characters are accessible.
There is only one sequence of characters which needs to ligate: TAMIL DIGIT ONE
௧ + TAMIL SIGN KALAM (which looks like TAMIL LETTER LLA ள) should always
ligate. I have also provided the ligature glyph after the glyphs for the
individual characters (mapped to PUA E03F) in the fonts 1 and 2 above. I have
not added any substitution mapping however as it is for now only temporarily in
the PUA.
Etcetera:
---------
It is my intention to submit the proposal within a week or so and I will
upload/link here a copy of the proposal.
If at all any changes are required to the set of glyphs as a result of any
feedback from scholars or other sources, I will upload fresh TTF font files.
I thank everyone, especially Pravin Satpute, for their support regarding this.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=841947
Bug ID: 841947
QA Contact: extras-qa(a)fedoraproject.org
Severity: unspecified
Version: rawhide
Priority: unspecified
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, psatpute(a)redhat.com
Assignee: psatpute(a)redhat.com
Summary: [te_IN] Add support for Telugu nakaarapollu and repha
to Lohit Telugu font
Regression: ---
Story Points: ---
Classification: Fedora
OS: Unspecified
Reporter: samjnaa(a)gmail.com
Type: Bug
Documentation: ---
Hardware: Unspecified
Mount Type: ---
Status: NEW
Component: lohit-telugu-fonts
Product: Fedora
Created attachment 599423
--> https://bugzilla.redhat.com/attachment.cgi?id=599423&action=edit
Glyphs for Telugu nakaarapollu and repha
Telugu script has special form of vowelless NA called four-pronged
nakaarapollu. Strictly speaking nakaarapollu means nakaara + pollu=virama so
regular form of vowelless-NA న్ is also nakaarapollu but Telugu old grammarian
Brown has specifically called a distinct form as nakaarapollu.
The recommended model for getting Telugu nakaarapollu is NA + ZWJ + VIRAMA.
Please find more details in the document:
https://sites.google.com/site/jamadagni/files/utcsubmissions/11409-telugu-n…
Likewise Telugu script has old repha form which is not found in common usage in
current Telugu script. A modern-style Telugu font can allow user to select
old-style reph by using the sequence RA + VIRAMA + ZWJ + CONSONANT because the
plain RA + VIRAMA + CONSONANT would be presented as RA with sub-base form of
CONSONANT.
Please find more details in the document:
https://sites.google.com/site/jamadagni/files/utcsubmissions/12017-telugu-r…
These two documents have been approved by the UTC in the Feb 2012 meeting:
http://www.unicode.org/L2/L2012/12007.htm
<quote>
[130-A15] Action Item for Deborah Anderson, Editorial Committee: Update the
core specification text on Telugu nakaara-pollu based on input in document
L2/11-409.
[130-A16] Action Item for Deborah Anderson: Incorporate text on Telugu Reph
from L2/12-017 into the Telugu block description.
</quote>
It is requested to:
1) add the glyphs for nakaarapollu and repha to the Lohit Telugu font:
2) add substitution mapping of NA + ZWJ + VIRAMA to the nakaarapollu glyph
3) add requisite OT markups for repha glyph so that a compliant OT system can
recognize the repha glyph and render sequence of RA + VIRAMA + ZWJ + CONS using
that glyph.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=982601
Bug ID: 982601
Summary: [ml_IN] Addition of glyphs to Lohit Malayalam to
support recently proposed Unicode characters
Product: Fedora
Version: rawhide
Component: lohit-malayalam-fonts
Severity: unspecified
Priority: unspecified
Assignee: psatpute(a)redhat.com
Reporter: samjnaa(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, psatpute(a)redhat.com
Created attachment 770964
--> https://bugzilla.redhat.com/attachment.cgi?id=770964&action=edit
Glyphs for Malayalam Archaic II, minor fractions and Chillu LLL
Recently I and Cibu Johny have proposed various characters to be added to the
Malayalam Unicode block and in the last May 2013 UTC meeting they have been
approved and further (IIUC) approved by the WG2 meeting last month in Lithunia.
The links are provided below:
N4429 Proposal to encode Malayalam minor fractions
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n4429.pdf
N4428 Proposal to encode MALAYALAM LETTER CHILLU LLL
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n4428.pdf
N4312 Proposal for MALAYALAM LETTER ARCHAIC II
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n4312.pdf
This is a placeholder bug (like bug #839303 for Tamil fractions and symbols) to
ensure that the requisite glyphs are added immediately once the characters are
published in the Unicode standard finally.
I have designed the glyphs for these proposed characters partially based on
existing glyphs from the Lohit Malayalam font and would like to submit these as
my contributions to the Lohit project under the OFL.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=CqoPzu7D2p&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1076190
Bug ID: 1076190
Summary: Rendering of Unicode tie bars could be improved
Product: Fedora
Version: 20
Component: liberation-fonts
Severity: low
Assignee: psatpute(a)redhat.com
Reporter: rkaldari(a)wikimedia.org
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com
Created attachment 874108
--> https://bugzilla.redhat.com/attachment.cgi?id=874108&action=edit
comparison between Liberation Sans and Helvetica
Description of problem:
The rendering of the two Unicode tie bar combining characters (U+035E and
U+035F) is not ideal. In particular the characters are quite short and far away
from the characters they are tying together. This makes it appear more like a
misplaced macron than a tie bar. The rendering in Liberation Sans appears to be
equivalent to that of Arial which has the same issues. The rendering in
Helvetica is better (see attachment 1).
In particular, because the under tie bar (U+035F) is so far away from the other
characters, it sometimes gets clipped when rendered, as it appears to fall
slightly outside of the bounding box for the line height (see attachment 2).
My suggestion would be to make the length of both tie bars slightly longer, and
to move both of them slightly closer to the characters they are intended to tie
together.
Version-Release number of selected component (if applicable):
12-Mar-2014 (2.x)
How reproducible:
Always
Steps to Reproduce:
1. Install latest Liberation Sans (and Helvetica if you want to compare)
2. Go to https://www.mediawiki.org/wiki/User:Kaldari/Font_test_2
Actual results:
Tie bars should be slightly longer and closer to the other characters.
Expected results:
Tie bar are quite short and far away.
Additional info:
See attachments for more info.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=4qagSOJtp5&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1084227
Bug ID: 1084227
Summary: Arrow symbols too small and not nicely aligned
Product: Fedora
Version: 20
Component: liberation-fonts
Assignee: psatpute(a)redhat.com
Reporter: Eduard.Braun2(a)gmx.de
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com
Created attachment 882471
--> https://bugzilla.redhat.com/attachment.cgi?id=882471&action=edit
testcase with some exemplary arrows
The arrow symbols contained in Liberation fonts seem to be too small and also a
little mis-aligned.
As an example consider the attached testcase which contains left/right/up/down
arrows exemplarily. The attached screenshot is a rendering of this file to
illustrate the issue:
- The arrows are much to small making them hardly discernible,
especially at small font sizes.
- The horizontally aligned arrows are positioned too low (nearly at the
baseline).
- Also visible: Hinting for the vertically aligned arrows is bad.
The screenshot was created with Firefox 28.0 on Windows 7.
The installed version of the Liberation fonts is 2.00.1
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=kmf7UnRYux&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1409348
Bug ID: 1409348
Summary: Some fonts (such as Droid Sans) don't work anymore on
some websites with Firefox
Product: Fedora
Version: 25
Component: google-droid-fonts
Assignee: nicolas.mailhot(a)laposte.net
Reporter: nekohayo(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
hobbes1069(a)gmail.com, nicolas.mailhot(a)laposte.net,
paul(a)frixxon.co.uk, tremble(a)tremble.org.uk
Screenshot: https://bug1257709.bmoattachments.org/attachment.cgi?id=8731947
Sample website: http://jeff.ecchi.ca
This website uses the Droid Sans fonts, but somehow Firefox
I had originally filed a bug on Firefox at
https://bugzilla.mozilla.org/show_bug.cgi?id=1257709 but from what I can see
now this is actually a bug that is specific to Fedora—either Fedora's version
of Firefox, or Fedora's version of the Google Droid fonts:
- The issue does not occur on Firefox on other OSes
(OpenSUSE Tumbleweed, Ubuntu, Mac OS X).
- The issue does not occur if you do "dnf remove google-droid*"
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1398676
Bug ID: 1398676
Summary: Pango sometimes shows a replacement character for
space (U+0020) when a font lacks a space
Product: Fedora
Version: 25
Component: pango
Assignee: tagoh(a)redhat.com
Reporter: mfabian(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, tagoh(a)redhat.com
Created attachment 1224372
--> https://bugzilla.redhat.com/attachment.cgi?id=1224372&action=edit
pango-bug.png
Tested on the released version of Fedora 25.
pango-1.40.3-1.fc25.x86_64
When using a font which does not have a space, Pango may show a replacement
character for space( U+0020).
I’ll attach the file rovas.txt which has a first line containing only Old
Hungarian
script and a space.
I’ll also attach an old Hungarian font taken from
https://github.com/OldHungarian/old-hungarian-font/releases which lacks a
space.
Display the test file like this:
pango-view --font="Old Hungarian" ~/rovas.txt
And you get something as in the also attached screenshot which shows
that Pango renders the space as an replacement character.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1319249
Bug ID: 1319249
Summary: incorrect use of Requires(pre)?
Product: Fedora
Version: rawhide
Component: ghostscript-fonts
Assignee: twaugh(a)redhat.com
Reporter: jsilhan(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org, twaugh(a)redhat.com
We've identified your package for having `Requires(pre)` RPM flag without
`Requires` [1]. `Requires(pre)` rpm tag could be interpreted wrongly, so to
prevent any harm to Fedora users I am notifying you about this fact.
Any package that is specified in `Requires(pre)` could be freely removed.
Citing from RPM pages:
```
If there are no other dependencies on the package providing /usr/sbin/useradd,
that package is permitted to be removed from the system after installation(!)
``` [2]
If you really rely on dependency just during the installation process and your
package don't necessary require the dependency for the proper run of your
application then ignore this bug report and close it as NOTABUG. Otherwise add
to your spec file additional `Requires` for the dependency, please.
[1] paste.fedoraproject.org/341611/82208431
[2] http://www.rpm.org/wiki/PackagerDocs/MoreOnDependencies
--
You are receiving this mail because:
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Please convert to new font packaging guidelines
https://bugzilla.redhat.com/show_bug.cgi?id=477389
Summary: Please convert to new font packaging guidelines
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: medium
Component: ghostscript-fonts
AssignedTo: twaugh(a)redhat.com
ReportedBy: nicolas.mailhot(a)laposte.net
QAContact: extras-qa(a)fedoraproject.org
CC: twaugh(a)redhat.com, fedora-fonts-bugs-list(a)redhat.com
Classification: Fedora
This bug has been filed because we've detected your package includes one or
several font files:
repoquery -C --repoid=rawhide -f '*.ttf' -f '*.otf' -f '*.pfb'
-f '*.pfa' --qf='%{SOURCERPM}\n' |sed -e
's+-[0-9.-]*\.fc[123456789]\(.*\)src.rpm++g'|sort|uniq
Unfortunately the script
does not detect symlinks to other packages, so if that's your case, you can
close this bug report now.
Otherwise, you should know that:
- Fedora guidelines
demand the packaging of fonts in a separate package or subpackage:
http://fedoraproject.org/wiki/Packaging/Guidelines#Avoid_bundling_of_fonts_…
- our font packaging guidelines recently changed, and every package that ships
fonts must be adapted to the new templates available in the fontpackages-devel
package.
http://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation_(2…http://fedoraproject.org/wiki/Fedora_fonts_policy_packagehttp://fedoraproject.org/wiki/Simple_fonts_spec_templatehttp://fedoraproject.org/wiki/Fonts_spec_template_for_multiple_fonts
Please make
your package conform to the current guidelines in rawhide.
If your package is not
principaly a font package, depending on a separate font package or subpackage
is the prefered solution. If your application does not use fontconfig you can
always package symlinks to the files provided by the font package and installed
in the correct fontconfig directories.
It is preferred to make a font package or
subpackage per font family, though it is not currently a hard guidelines
requirement (it may become before Fedora 11 is released). The definition of a
font family is given on
http://fedoraproject.org/wiki/Fonts_spec_template_notes/font-family
The new
templates should make the creation of font subpackages easy and safe.
The
following packages have already been converted and can serve as examples: -
andika-fonts - apanov-heuristica-fonts - bitstream-vera-fonts - charis-fonts -
dejavu-fonts - ecolier-court-fonts - edrip-fonts - gfs-ambrosia-fonts -
gfs-artemisia-fonts - gfs-baskerville-fonts - gfs-bodoni-classic-fonts -
gfs-bodoni-fonts - gfs-complutum-fonts - gfs-didot-classic-fonts -
gfs-didot-fonts - gfs-eustace-fonts - gfs-fleischman-fonts - gfs-garaldus-fonts
- gfs-gazis-fonts - gfs-jackson-fonts - gfs-neohellenic-fonts -
gfs-nicefore-fonts - gfs-olga-fonts - gfs-porson-fonts - gfs-solomos-fonts -
gfs-theokritos-fonts - stix-fonts - yanone-kaffeesatz-fonts
If you have any remaining
questions about the new guidelines please ask them on fedora-fonts-list at
redhat.com
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1504433
Bug ID: 1504433
Summary: thai-arundina-fonts-0.2.2 is available
Product: Fedora
Version: rawhide
Component: thai-arundina-fonts
Keywords: FutureFeature, Triaged
Assignee: pwu(a)redhat.com
Reporter: upstream-release-monitoring(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, pwu(a)redhat.com
Latest upstream release: 0.2.2
Current version/release in rawhide: 0.2.1-3.fc27
URL: http://linux.thai.net/pub/thailinux/software/fonts-sipa-arundina/
Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy
More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring
Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.
Based on the information from anitya:
https://release-monitoring.org/project/4964/
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1503250
Bug ID: 1503250
Summary: Outdated package
Product: Fedora
Version: 26
Component: adobe-source-sans-pro-fonts
Assignee: alexis.lameire(a)gmail.com
Reporter: hitori.gm(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: alexis.lameire(a)gmail.com,
fonts-bugs(a)lists.fedoraproject.org,
pikachu.2014(a)gmail.com
Current package version (1.050-7) is 3 years old which is missing Cyrillic and
Greek support.
The latest version (2.020R-ro/1.075R-it) can be found at
https://github.com/adobe-fonts/source-sans-pro/releases/tag/2.020R-ro%2F1.0…
P.S.: bug 1246765 has a patch with updated spec provided by Michael Kuhn.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1469712
Bug ID: 1469712
Summary: font antialiasing/hinting is not working on Fedora 26
Product: Fedora
Version: 26
Component: freetype
Severity: high
Assignee: mkasik(a)redhat.com
Reporter: mchehab(a)infradead.org
QA Contact: extras-qa(a)fedoraproject.org
CC: behdad(a)fedoraproject.org,
fonts-bugs(a)lists.fedoraproject.org,
kevin(a)tigcc.ticalc.org, mkasik(a)redhat.com
Description of problem:
After upgrading from Fedora 25 to Fedora 26, font hinting doesn't work anymore.
All fonts look really ugly on my 32' monitor, and changing font antialias/hint
options at Gnome, Plasma or Mate doesn't produce any visible changes anymore.
With Fedora 25, I used freetype-freeword from rpmfusion, as it produced a
better result than the default freetype font hinting (although both work). On
Fedora 26, neither with or without freetype-freeword I can adjust font
hint/antialias anymore, as those options don't work anymore.
Version-Release number of selected component (if applicable):
freetype-2.7.1-9.fc26.x86_64
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1470509
Bug ID: 1470509
Summary: freetype/harfbuzz fc25->fc26 turns to ugly rendering
Product: Fedora
Version: 26
Component: freetype
Severity: medium
Assignee: mkasik(a)redhat.com
Reporter: pb(a)bieringer.de
QA Contact: extras-qa(a)fedoraproject.org
CC: behdad(a)fedoraproject.org,
fonts-bugs(a)lists.fedoraproject.org,
kevin(a)tigcc.ticalc.org, mkasik(a)redhat.com
Description of problem:
While on fc25 I have sharp fonts on a 1600x1200 96 dpi display after upgrade to
fc26 the rendering is ugly
Version-Release number of selected component (if applicable):
freetype-2.7.1-9.fc26.x86_64
harfbuzz-1.4.4-1.fc26.x86_64
harfbuzz-icu-1.4.4-1.fc26.x86_64
(from updates-testing)
+ fc26 original
How reproducible:
at least on 2 systems
Steps to Reproduce:
1. upgrade to fc26
2. login
Actual results:
bad system font rendering
Expected results:
same rendering as on fc25
Additional info:
# xrdb -q
Xft.lcdfilter: lcddefault
Xft.antialias: 0
Xft.hinting: 1
Xft.hintstyle: hintslight
Xft.rgba: rgb
Xft.dpi: 96
Xcursor.theme: default
Xcursor.size: 21
Xcursor.theme_core: 1
after downgrade with fc25 packages:
freetype-2.6.5-1.fc25.x86_64.rpm
harfbuzz-1.3.2-1.fc25.x86_64.rpm
harfbuzz-icu-1.3.2-1.fc25.x86_64.rpm
after reboot returns to previous and well rendering behavior.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1506926
Akira TAGOH <tagoh(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|POST |CLOSED
Resolution|--- |NEXTRELEASE
Last Closed| |2017-10-31 06:09:22
--- Comment #3 from Akira TAGOH <tagoh(a)redhat.com> ---
thanks. built on rawhide.
https://koji.fedoraproject.org/koji/packageinfo?packageID=25500
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1506925
Akira TAGOH <tagoh(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|POST |CLOSED
Resolution|--- |NEXTRELEASE
Last Closed| |2017-10-31 06:08:19
--- Comment #3 from Akira TAGOH <tagoh(a)redhat.com> ---
thanks. built on rawhide.
https://koji.fedoraproject.org/koji/packageinfo?packageID=25501
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1506918
Akira TAGOH <tagoh(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|POST |CLOSED
Resolution|--- |NEXTRELEASE
Last Closed| |2017-10-31 05:39:50
--- Comment #3 from Akira TAGOH <tagoh(a)redhat.com> ---
thanks. built on rawhide.
https://koji.fedoraproject.org/koji/packageinfo?packageID=25518
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1506916
Akira TAGOH <tagoh(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|POST |CLOSED
Resolution|--- |NEXTRELEASE
Last Closed| |2017-10-31 04:50:31
--- Comment #4 from Akira TAGOH <tagoh(a)redhat.com> ---
thanks. built on rawhide.
https://koji.fedoraproject.org/koji/packageinfo?packageID=25509
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1496466
--- Comment #20 from Federico Bruni <fede(a)inventati.org> ---
Sure, no hurry here :)
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1496466
--- Comment #19 from David Kaspar [Dee'Kej] <dkaspar(a)redhat.com> ---
Thank you Federico for the info. :)
Unfortunately, I'm currently really busy with my primary work responsibilities.
I hope to look at this next week.
My guess is that this will land into F27 updates repo (too late for Final
Freeze) and Rawhide. Is this okay for you?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1506961
Robert-André Mauchin <zebob.m(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |POST
Flags|fedora-review? |fedora-review+
--- Comment #3 from Robert-André Mauchin <zebob.m(a)gmail.com> ---
Perfect, package accepted.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1506961
Robert-André Mauchin <zebob.m(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
CC| |zebob.m(a)gmail.com
Assignee|nobody(a)fedoraproject.org |zebob.m(a)gmail.com
Flags| |fedora-review?
--- Comment #1 from Robert-André Mauchin <zebob.m(a)gmail.com> ---
Hello,
- Source0 is returning error 404. Use this instead:
Source0:
https://github.com/adobe-fonts/source-han-code-jp/archive/%{version}R/%{arc…
- The README.md file has executable permissions, this isn't good. Remove the
executable bits in %prep and notify upstream about this issue.
chmod 0644 README.md
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1506916
Robert-André Mauchin <zebob.m(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |POST
CC| |zebob.m(a)gmail.com
Assignee|nobody(a)fedoraproject.org |zebob.m(a)gmail.com
Flags| |fedora-review+
--- Comment #2 from Robert-André Mauchin <zebob.m(a)gmail.com> ---
Package accepted.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1506926
Robert-André Mauchin <zebob.m(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |POST
CC| |zebob.m(a)gmail.com
Assignee|nobody(a)fedoraproject.org |zebob.m(a)gmail.com
Flags| |fedora-review+
--- Comment #1 from Robert-André Mauchin <zebob.m(a)gmail.com> ---
Package is good and accepted.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1506925
Robert-André Mauchin <zebob.m(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |POST
CC| |zebob.m(a)gmail.com
Assignee|nobody(a)fedoraproject.org |zebob.m(a)gmail.com
Flags| |fedora-review+
--- Comment #1 from Robert-André Mauchin <zebob.m(a)gmail.com> ---
Package accepted.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1506918
Robert-André Mauchin <zebob.m(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |POST
CC| |zebob.m(a)gmail.com
Assignee|nobody(a)fedoraproject.org |zebob.m(a)gmail.com
Flags| |fedora-review+
--- Comment #1 from Robert-André Mauchin <zebob.m(a)gmail.com> ---
Hello,
Package is good and accepted.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1506961
Akira TAGOH <tagoh(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fonts-bugs(a)lists.fedoraproj
| |ect.org
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1506916
David Kaspar [Dee'Kej] <dkaspar(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dkaspar(a)redhat.com
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1506926
Akira TAGOH <tagoh(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fonts-bugs(a)lists.fedoraproj
| |ect.org
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1506925
Akira TAGOH <tagoh(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fonts-bugs(a)lists.fedoraproj
| |ect.org
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1506918
Akira TAGOH <tagoh(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fonts-bugs(a)lists.fedoraproj
| |ect.org
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1506916
Akira TAGOH <tagoh(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fonts-bugs(a)lists.fedoraproj
| |ect.org
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1496466
--- Comment #18 from Federico Bruni <fede(a)inventati.org> ---
David, OTF files would be useful also to be able to compile LilyPond (a music
typesetting program, packaged in Fedora) without a warning:
WARNING: Please consider installing optional programs or files: URW++ OTF
fonts
These files are optional but it would be nice to have them.
Recent discussion on the subject is here:
http://lists.gnu.org/archive/html/lilypond-devel/2017-10/msg00141.html
Thanks for your efforts
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1500695
Bug ID: 1500695
Summary: CVE-2017-13720 CVE-2017-13722 libXfont: various flaws
[fedora-all]
Product: Fedora
Version: 26
Component: libXfont
Keywords: Security, SecurityTracking
Severity: low
Priority: low
Assignee: btissoir(a)redhat.com
Reporter: anemec(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: ajax(a)redhat.com, alexl(a)redhat.com,
btissoir(a)redhat.com, caillon+fedoraproject(a)gmail.com,
caolanm(a)redhat.com,
fonts-bugs(a)lists.fedoraproject.org,
jglisse(a)redhat.com, john.j5live(a)gmail.com,
mbarnes(a)fastmail.com, rhughes(a)redhat.com,
rstrode(a)redhat.com, sandmann(a)redhat.com
This is an automatically created tracking bug! It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of fedora-all.
For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.
For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs
When submitting as an update, use the fedpkg template provided in the next
comment(s). This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.
Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg commit message.
NOTE: this issue affects multiple supported versions of Fedora. While only
one tracking bug has been filed, please correct all affected versions at
the same time. If you need to fix the versions independent of each other,
you may clone this bug as appropriate.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1497579
Bug ID: 1497579
Summary: python-fontMath-0.4.4 is available
Product: Fedora
Version: rawhide
Component: python-fontMath
Keywords: FutureFeature, Triaged
Assignee: athoscribeiro(a)gmail.com
Reporter: upstream-release-monitoring(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: athoscribeiro(a)gmail.com,
fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, pnemade(a)redhat.com
Latest upstream release: 0.4.4
Current version/release in rawhide: 0.4.3-3.fc27
URL: https://pypi.python.org/pypi/fontMath
Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy
More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring
Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.
Based on the information from anitya:
https://release-monitoring.org/project/13898/
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1258542
Shawn Starr <shawn.starr(a)rogers.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends On| |1440971
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1440971
[Bug 1440971] Review Request: python-pyclipper - Cython wrapper for the
C++ translation of the Angus Johnson's Clipper library
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1498747
Bug ID: 1498747
Summary: gv is not finding standard postscript fonts like
Times-Roman
Product: Fedora
Version: 27
Component: urw-fonts
Severity: medium
Assignee: dkaspar(a)redhat.com
Reporter: nvwarr(a)hotmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: dkaspar(a)redhat.com,
fonts-bugs(a)lists.fedoraproject.org, than(a)redhat.com
Created attachment 1334637
--> https://bugzilla.redhat.com/attachment.cgi?id=1334637&action=edit
Simple eps file to illustrate the problem
Description of problem:
gv is not finding the standard postscript fonts like Times-Roman. The same is
true of epstopdf (from texlive-epstopdf-bin) and gs.
Version-Release number of selected component (if applicable):
gv-3.7.4-14.fc27.x86_64
How reproducible:
always
Steps to Reproduce:
1. gv circle.eps (with the attached eps file)
Actual results:
shows the circle and gives an invalid font error message and does not show the
text "circle" which should be in the middle of the circle.
Expected results:
should show the circle with the text in the middle without an error message.
Additional info:
It works fine on Fedora 26 with:
gv-3.7.4-12.fc26.x86_64
On Fedora 26, these fonts belong to urw-fonts. According to
dnf whatprovides /usr/share/fonts/default/Type1
the package urw-fonts still exists and still provides the directory where the
fonts should be, but it can't be installed because of a conflict:
dnf install urw-fonts
gives:
Package urw-base35-fonts-20170801-2.fc27.noarch is already installed, skipping.
Manually copying the fonts from the Fedora 26 to the Fedora 27 system fixes the
problem.
So it seems to be a packaging issue.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1376476
David Kaspar [Dee'Kej] <dkaspar(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |CLOSED
Fixed In Version| |urw-base35-fonts-20170801-2
| |.fc28,
| |urw-base35-fonts-20170801-2
| |.fc27
Resolution|--- |ERRATA
Last Closed|2017-05-13 21:35:43 |2017-10-04 11:31:19
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1376476
Bug 1376476 depends on bug 1458840, which changed state.
Bug 1458840 Summary: Review Request: urw-base35-fonts - Level 2 Core Font Set for Ghostscript
https://bugzilla.redhat.com/show_bug.cgi?id=1458840
What |Removed |Added
----------------------------------------------------------------------------
Status|ON_QA |CLOSED
Resolution|--- |ERRATA
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1498063
Bug ID: 1498063
Summary: fonttools-3.16.0 is available
Product: Fedora
Version: rawhide
Component: fonttools
Keywords: FutureFeature, Triaged
Assignee: pnemade(a)redhat.com
Reporter: upstream-release-monitoring(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
pnemade(a)redhat.com, sshedmak(a)redhat.com
Latest upstream release: 3.16.0
Current version/release in rawhide: 3.15.1-1.fc28
URL: https://github.com/fonttools/fonttools/
Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy
More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring
Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.
Based on the information from anitya:
https://release-monitoring.org/project/7388/
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1496466
--- Comment #17 from David Kaspar [Dee'Kej] <dkaspar(a)redhat.com> ---
Thanks for the explanation. That might help me to keep a little pressure on
Ghostscript for them to move to OTF at some point. :)
(In reply to Nicolas Mailhot from comment #16)
> All the usual suspects that concentrate "my text does not work" questions on
> Stack overflow…
Heh, yeah. :D You've summed it up perfectly. I guess I should create a new
tracking BZ in the future to track which of these apps now support OTF and
which not.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1496466
--- Comment #16 from Nicolas Mailhot <nicolas.mailhot(a)laposte.net> ---
(In reply to David Kaspar [Dee'Kej] from comment #14)
> And as I mentioned in my previous comment, the ImageMagick also expects the
> Type1 /AFM fonts, and I expect there are some other applications might
> require it as well. Here's the list of packages requiring the old
> 'urw-fonts' package:
>
> ghostscript-core
> grace
> GraphicsMagick
> graphviz
> htmldoc
> ipe
> libwmf
> mscgen
> pdf-renderer
> pokerth
> root-core
> synfig
> xpdf
> ImageMagick
All the usual suspects that concentrate "my text does not work" questions on
Stack overflow…
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1496466
--- Comment #15 from Nicolas Mailhot <nicolas.mailhot(a)laposte.net> ---
(In reply to David Kaspar [Dee'Kej] from comment #13)
> Looking at the sizes of the OTF and TTF, the OTF seems to be "compressed",
> therefore in order to save users' space, I would again vote for using this
> format.
TTF uses quadratic splines whereas OTF uses cubic splines. Type1 uses cubic
splines. That's why you can get lossless glyph shape conversion between Type1
and OTF but not between Type1 and TTF, and why upstream wrote they absolutely
needed a CFF format to make sure there was no deviation in metrics from the
standard.
(One can approximate a cubic spline with a series of quadratic splines, that's
how font tools convert Type1/OTF to TTF, the result is good enough for the
human eye, but technically it's not lossless. In your case absolutely no
deviation is better than minimal deviations given the glyph sizes are
standardised).
That's why generally speaking it's better to use OTF when evolving a Type1
font, except for legacy windows-oriented apps that understand TTF but not OTF.
Linux systems do not care they have good support both for OTF and for TTF.
Hardware has passed the point where computing cubics was significantly more
expensive than computing quadratics a long time ago.
The spline part of OTF files is more compact than Type1. One is CFF2 the other
is CFF1 — they are mathematically equivalent but the state of the art had
improved between both specs (both written essentially by Adobe).
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1496466
--- Comment #14 from David Kaspar [Dee'Kej] <dkaspar(a)redhat.com> ---
(In reply to Nicolas Mailhot from comment #12)
> BTW OTF *is* the OpenType (SFNT) format used to ship CFF outlines nowadays
> so unless upstream did something really weird with its OTF files they
> satisfy :
>
> # According to upstream, Ghostscript needs only Type 1 fonts to work
> properly.
> # It can use TTF or OTF fonts as substitutions as well in case the Type 1
> # fonts are missing, but the substitution is not (and can't be)
> guaranteed to
> # be absolutely flawless, unless the fonts use the CFF outlines:
> # > https://en.wikipedia.org/wiki/PostScript_fonts#Compact_Font_Format
>
> https://blog.typekit.com/2010/12/02/the-benefits-of-opentypecff-over-
> truetype/
Yeah, I realize that. That's why there's that additional note in specfile, that
even though most of the Ghostscript should work with OTF now, the 'pdfwrite'
device is still not able to do so... :-/
And as I mentioned in my previous comment, the ImageMagick also expects the
Type1 /AFM fonts, and I expect there are some other applications might require
it as well. Here's the list of packages requiring the old 'urw-fonts' package:
ghostscript-core
grace
GraphicsMagick
graphviz
htmldoc
ipe
libwmf
mscgen
pdf-renderer
pokerth
root-core
synfig
xpdf
ImageMagick
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1496466
--- Comment #13 from David Kaspar [Dee'Kej] <dkaspar(a)redhat.com> ---
(In reply to Nicolas Mailhot from comment #10)
> That's a poor situation to be in, but yes the minimum would be to ship the
> OpenType¹ versions as required by Fedora packaging guidelines, and maybe
> hide somewhere the Type1/AFM versions for GS private use (after asking
> Fesco). The first priority would be to avoid Ghostscript blocking progress
> in other apps that want to use those fonts. If that can help you in any way,
> you have my blessing, for the little it is worth.
I'm OK to ship it all together (i.e. *.t1 living next to *.otf), in order for
the fonts to have the same file path (I would like to avoid creating a symlinks
in that folder). The reason why we now need the Type1 to be living in that
exact folder name is that ImageMagick has just added support for
'urw-base35-fonts' and it is expecting the Type1 fonts in that specific
location:
https://github.com/ImageMagick/ImageMagick/commit/fbca0d09324006b66b01e
(I forgot to mention that there are other packages still depending on the Type1
format - ImageMagick is the one of them, and AFAICT there are others.)
> As an aside I understand the reluctance of Ghostscript upstream to switch
> from "proven" Type1 fonts but let's be honest, Ghostscript is fed all kinds
> of stuff by third-party apps, the Type1 support of those apps is going away,
> they *will* preferentially use OpenType files, so long term there will be
> all sorts of subtle discrepancies between a Ghostscript that understands URW
> as "Type1", and the rest of the world that thinks "Opentype". But that's
> typically a "choose your poison" situation for the Ghostscript maintainer,
> it need not impact the rest of the distro the way it does now.
You're getting to the core of the problem here actually. As I mentioned before,
Ghostscript upstream does not want to switch to OTF/TTF, because one of their
"devices" (inside of Ghostscript called 'pdfwrite', used for conversions, etc.)
would not work in quite few scenarios (I had some bug reports about it before
IIRC), thus making the PS->PDF and PDF->PS conversions not working.
So as the rest of the World is slowly starting to use the OTF/TTF, the
Ghostscript is using Type1 fonts (converted from the OTF files actually), and
they most likely will be doing it for a long time to come. That's because they
are bundling the Type1 fonts with the Ghostscript vanilla sources, so they do
not need to care about the rest of the World going with OTF.
And that's because of the FPG that we actually ship a separate package for
these fonts (because FPG forbids bundling of software, unless there is an
exception from FESco). And that's why many other distros IMHO do not face these
problems, because they do not care so much about bundling the software - they
built it from vanilla sources (with a lots of other bundled libraries, etc.)
and just ship it. When this happens, they can have both OTF fonts and Type1
fonts living next to each other. (Type1 is being shipped as part of
Ghostscript's resources.)
Looking at the sizes of the OTF and TTF, the OTF seems to be "compressed",
therefore in order to save users' space, I would again vote for using this
format.
So to conclude, I will take this to a FESco, but I need to find out how to do
this officially first. And I'm currently being under time pressure both from my
primary job responsibilities and F27 release schedule - because the process of
putting this package into F27 is already underway, and I can't stop it anymore
- other packages are currently depending on it as well.
In this case, I will probably take the way of "EAFP" instead of "LBYL", make
the changes ASAP, and then inform FESco about this and "ask for forgiveness"...
:D
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1496466
--- Comment #12 from Nicolas Mailhot <nicolas.mailhot(a)laposte.net> ---
BTW OTF *is* the OpenType (SFNT) format used to ship CFF outlines nowadays so
unless upstream did something really weird with its OTF files they satisfy :
# According to upstream, Ghostscript needs only Type 1 fonts to work
properly.
# It can use TTF or OTF fonts as substitutions as well in case the Type 1
# fonts are missing, but the substitution is not (and can't be) guaranteed
to
# be absolutely flawless, unless the fonts use the CFF outlines:
# > https://en.wikipedia.org/wiki/PostScript_fonts#Compact_Font_Formathttps://blog.typekit.com/2010/12/02/the-benefits-of-opentypecff-over-truety…
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1496466
--- Comment #11 from David Kaspar [Dee'Kej] <dkaspar(a)redhat.com> ---
(In reply to Nicolas Mailhot from comment #9)
> Note however that Appstream for fonts was heavily influenced by Debian, and
> Debian didn't rebase its font packaging around fontconfig as Fedora did a
> few years ago, so a lot of the "Need to do foo in appstream because
> fontconfig is insufficient or fonts are broken" do not really apply for
> Fedora.
>
> If the font metadata is bad for example Fedora would prefer the packager to
> fix the font and patch the metadata rather than hide the brokenness under an
> Appstream overlay (which won't exist for apps that use the fonts anyway).
I see. :) Well, I hope the AppStream and fontconfig metadata are mostly OK for
the moment - at least for the urw-base35-fonts. I've spent a lot of time to get
it right.
(Currently, there was a small issue with typo in AppStream metadata that has a
pull-request waiting for acceptance, and small issue with Standard Symbols PS
being to big when used for LGC fonts.)
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1496466
--- Comment #10 from Nicolas Mailhot <nicolas.mailhot(a)laposte.net> ---
(In reply to David Kaspar [Dee'Kej] from comment #7)
> Do you have any suggestion on how to proceed from here? Should I take this
> to FESco and ask for official exception/permission to ship both Type1/AFM
> and OTF formats?
That's a poor situation to be in, but yes the minimum would be to ship the
OpenType¹ versions as required by Fedora packaging guidelines, and maybe hide
somewhere the Type1/AFM versions for GS private use (after asking Fesco). The
first priority would be to avoid Ghostscript blocking progress in other apps
that want to use those fonts. If that can help you in any way, you have my
blessing, for the little it is worth.
As an aside I understand the reluctance of Ghostscript upstream to switch from
"proven" Type1 fonts but let's be honest, Ghostscript is fed all kinds of stuff
by third-party apps, the Type1 support of those apps is going away, they *will*
preferentially use OpenType files, so long term there will be all sorts of
subtle discrepancies between a Ghostscript that understands URW as "Type1", and
the rest of the world that thinks "Opentype". But that's typically a "choose
your poison" situation for the Ghostscript maintainer, it need not impact the
rest of the distro the way it does now.
¹ Probably OTF not TTF given the Type1 history of those fonts
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1094015
Robert-André Mauchin <zebob.m(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |zebob.m(a)gmail.com
Blocks| |177841 (FE-NEEDSPONSOR)
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=177841
[Bug 177841] Tracker: Review requests from new Fedora packagers who need a
sponsor
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1496466
Nicolas Mailhot <nicolas.mailhot(a)laposte.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags|needinfo? |
--- Comment #9 from Nicolas Mailhot <nicolas.mailhot(a)laposte.net> ---
> (In reply to Nicolas Mailhot from comment #3)
> > It does not matter if they are packaged as texlive subpackages or as
> > independent projects as long as the template is applied. Also, whoever
> > packages them needs to ship some fontconfig files that aliases the various
> > past names of the fonts to the new one for backwards compat. Again there are
> > templates to do so in fontpackages-devel.
>
> That's another issue. Ideally, the good fonts should not only have the
> fontconfig files properly created for them, but AppStream files as well.
Yes, Appstream is yet another thing to have.
Note however that Appstream for fonts was heavily influenced by Debian, and
Debian didn't rebase its font packaging around fontconfig as Fedora did a few
years ago, so a lot of the "Need to do foo in appstream because fontconfig is
insufficient or fonts are broken" do not really apply for Fedora.
If the font metadata is bad for example Fedora would prefer the packager to fix
the font and patch the metadata rather than hide the brokenness under an
Appstream overlay (which won't exist for apps that use the fonts anyway).
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1496466
David Kaspar [Dee'Kej] <dkaspar(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |needinfo?
--- Comment #8 from David Kaspar [Dee'Kej] <dkaspar(a)redhat.com> ---
(In reply to Nicolas Mailhot from comment #3)
> Reading
> http://www.gust.org.pl/projects/e-foundry/tex-gyre/index_html#Licensing
>
> they got URW to publish the fonts under their own pet license to avoid
> dealing with Ghostscript licensing they didn't understood. So as long as
> they rebased to that release with no ghostscript import they are ok
> legal-wise (do check with spot if you feel like it, though I'm pretty sure
> he'd have blocked them from TexLive during its TEX audits if there was still
> a problem).
>
> That sucks if GS added fixes over URW material, but that's how free software
> works when projects disagree on licensing.
Actually, that note mentions Ghostscript 4.0, which is really old. We currently
have 9.X for a quite long time in Fedora now. That might be worth poking in it,
to see what the current status is... :)
(In reply to Nicolas Mailhot from comment #1)
> Someone should really package tex gyre in Fedora, now that the legal issues
> have been solved (IIRC). That's basically the same fonts in an opentype
> container.
Sorry, I'm not going through that rabbit hole again... :D The reason I went
into updating urw-base35-fonts was that those are needed by ghostscript, and I
want to finally fix all the issues related to f***ed building process. However,
if you want, feel free to take inspiration from urw-base35-fonts specfile:
https://src.fedoraproject.org/rpms/urw-base35-fonts/blob/master/f/urw-base3…
It should be more or less OK (I'm trying to keep it up-to-date), and should be
well commented.
(In reply to Nicolas Mailhot from comment #3)
> It does not matter if they are packaged as texlive subpackages or as
> independent projects as long as the template is applied. Also, whoever
> packages them needs to ship some fontconfig files that aliases the various
> past names of the fonts to the new one for backwards compat. Again there are
> templates to do so in fontpackages-devel.
That's another issue. Ideally, the good fonts should not only have the
fontconfig files properly created for them, but AppStream files as well. I had
to create/copy & modify those files manually for urw-base35-fonts, and it took
quite some effort to convince usptream to include them in their releases.
The AppStream for font files allow users to see the preview of them in Gnome
Software (and other software centers in other distros that are using
AppStream).
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1496466
David Kaspar [Dee'Kej] <dkaspar(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Flags|needinfo?(dkaspar(a)redhat.co |
|m) |
--- Comment #7 from David Kaspar [Dee'Kej] <dkaspar(a)redhat.com> ---
Hello guys, sorry for the delayed response, I had a vacation. :)
(In reply to Alexander Ploumistos from comment #6)
> David, I saw that the source package for urw-base35-fonts contains afm, otf,
> t1 and ttf formats. Is there a reason why you left OpenType and TrueType out?
Actually, there is. I was also up for using either TTF or OTF formats for
shipping those fonts, but after long discussions with (URW)++ fonts upstream
(de-facto Artifex Company - creators of ghostscript), I was "forced" to use the
Type1 formats with the metrics files (AFM).
Here's the justification (excerpt from urw-base35-fonts' specfile):
# According to upstream, Ghostscript needs only Type 1 fonts to work
properly.
# It can use TTF or OTF fonts as substitutions as well in case the Type 1
# fonts are missing, but the substitution is not (and can't be) guaranteed
to
# be absolutely flawless, unless the fonts use the CFF outlines:
# > https://en.wikipedia.org/wiki/PostScript_fonts#Compact_Font_Format
#
# The AFM (Adobe Font Metrics) are useful for layout purposes of other
# applications, and they contain general font information and font metrics.
# These AFM files were distributed in the previous 'urw-fonts' package, so
in
# order to avoid possible regressions in the future, we need to continue
# distributing them.
# NOTE: Fedora Packaging Guidelines (FPG) requires to use OTF or TTF format:
#
https://fedoraproject.org/wiki/Choosing_the_right_font_format_to_package
#
# However, according to upstream, the OTF/TTF fonts cause problems
# with 'pdfwrite' if we try to use them as base35 fonts. Otherwise,
# they work fine, but according to upstream they will *never* be able
# to use OTF/TTF fonts as the base35.
#
# Since AFAIK no other package/utility requires the base35 fonts, and
# Type 1 fonts with the AFM files are necessary for ghostscript to
# function properly, this fonts package will only use these files. We
# are not shipping the OTF alongside Type 1/AFM, because that would
# approximately double the size of the packages, which is not wanted.
#
# In case the ghostscript (specifically 'pdfwrite' device) will start
# to work correctly with OTF fonts type, then we will make the switch.
I'm okay with shipping the fonts in the OTF format as well (it now easiery
after several discussions with upstream), but I would expect people to start
complaining about it that the fonts are duplicated on their systems and that
the size of the packages is doubled unnecessary.
Do you have any suggestion on how to proceed from here? Should I take this to
FESco and ask for official exception/permission to ship both Type1/AFM and OTF
formats?
Because right now, we are kind of in a dead-end situation:
* ghostscript will not work properly without Type1/AFM (and I've spent a lot
of time to calm things down with ghostscript upstream, and I don't want to mess
it up again - they kind of hated us already before, because we kept messing
with their software improperly and they were receving not relevant bug reports
because of it)
* the new LibreOffice will not work with the old Type1/AFM and it needs the
OTF, as you said
--
You are receiving this mail because:
You are on the CC list for the bug.