March 2020 - i18n-bugs - Fedora Mailing-Lists

[Fedora-i18n-bugs] [Bug 1806696] Cups can't detect file type when file type is UTF-8 Unicode text

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1806696 --- Comment #22 from Akira TAGOH <tagoh(a)redhat.com> --- Where did you set that locale? how about your system locale? if you have it as system locale, did you restart cups service after changing it? -- You are receiving this mail because: You are on the CC list for the bug.

4 years, 1 month

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 1806696] Cups can't detect file type when file type is UTF-8 Unicode text

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1806696 --- Comment #21 from Greta Watson <greta_watson(a)stanfordalumni.org> --- Filter still fails with LANG=C.UTF-8. -- You are receiving this mail because: You are on the CC list for the bug.

4 years, 1 month

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 1806696] Cups can't detect file type when file type is UTF-8 Unicode text

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1806696 Akira TAGOH <tagoh(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution|--- |NOTABUG Last Closed| |2020-03-11 04:23:54 --- Comment #20 from Akira TAGOH <tagoh(a)redhat.com> --- Well, that isn't a bug. the encoding under C locale isn't UTF-8. if you want to use UTF-8 in C locale, you should set LANG=C.UTF-8. -- You are receiving this mail because: You are on the CC list for the bug.

4 years, 1 month

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 1806696] Cups can't detect file type when file type is UTF-8 Unicode text

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1806696 Greta Watson <greta_watson(a)stanfordalumni.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(greta_watson@stan | |fordalumni.org) | --- Comment #19 from Greta Watson <greta_watson(a)stanfordalumni.org> --- I may have a way for you to reproduce the bug. It may have something to do with one of the KDE environment variables. So, if you are running KDE, set the LANG environment variable to C (export LANG=C). That should enable you to reproduce the bug. When I unset LANG, the problem did not occur. -- You are receiving this mail because: You are on the CC list for the bug.

4 years, 1 month

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 1806696] Cups can't detect file type when file type is UTF-8 Unicode text

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1806696 --- Comment #18 from Greta Watson <greta_watson(a)stanfordalumni.org> --- Found the file, and the corresponding file that starts with the letter c. In the latter file, the error message reads that there is no reason for the failure. Is this what you wanted? I'm confused. -- You are receiving this mail because: You are on the CC list for the bug.

4 years, 1 month

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 1806696] Cups can't detect file type when file type is UTF-8 Unicode text

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1806696 --- Comment #17 from Zdenek Dohnal <zdohnal(a)redhat.com> --- The file which goes from 'lp' to cupsd scheduler and which is going into texttopaps filter is in /var/spool/cups. It begins with 'd', has job id in its filename and ends with number of files in the job. f.e. file for job id 1, which has one file to print, is d00001-001. -- You are receiving this mail because: You are on the CC list for the bug.

4 years, 1 month

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 1806696] Cups can't detect file type when file type is UTF-8 Unicode text

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1806696 --- Comment #16 from Greta Watson <greta_watson(a)stanfordalumni.org> --- I would like to do what you ask, but need detailed instructions. This bug appears only when I use the lp command from the command line. If I look at the file with kwrite, and then print from within kwrite, it works. If I bring up the text file in my browser and try to print, it works okay. So please give me exactly what I should type into the xfce4 terminal (or gnome terminal, or konsole terminal to do what you need me to do. Thank-you. And sorry for having to ask, but I really do not understand the printing system. -- You are receiving this mail because: You are on the CC list for the bug.

4 years, 1 month

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 1806272] DejaVu has been repackaged in F32+ using new fonts packaging macros; those macros use an srpm-independent file layout and remove srpm-level sharing like the previous -common subpackage

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1806272 --- Comment #27 from Hans de Goede <hdegoede(a)redhat.com> --- (In reply to Nicolas Mailhot from comment #26) > (In reply to Hans de Goede from comment #24) > > Thank you for adding the compat packages. > > > > I must be honest though, this is not entirely what I was expecting. I was > > expecting the compat symlinks to be part of the main dejavu-sans-fonts, > > dejavu-serif-fonts, etc. packages. That way they will automatically just be > > there, without packages depending on say dejavu-sans-fonts needing to adjust > > their Requires. > > https://src.fedoraproject.org/rpms/dejavu-fonts/blob/f32/f/dejavu-fonts. > spec#_151 Ah I looked over the Supplements line, cool. Thank you this will give us a whole cycle to deal with the fallout of this, much appreciated. > > The idea here is to make things more future proof, so that we can deal with > > any future font-file-path changes with just a rebuild. > > It will be a little more future-proof, but not as much as you think. Fonts > are evolving outside the one style = one file model. Mostly, due to the > influence of web fonts, because CSS uses a stacking model, identical to the > one in fontconfig. Styles can now be spread over multiple files (that is > already true for the Math extension of DejaVu Serif) or, on the contrary, be > merged into a single file (variable fonts). Ok I understand, if: BuildRequires: font(dejavusans) fontconfig + fc-match -f "%{file}" "sans" Ever results in the second command suggesting a font which is not suitable as a default font for "legacy" ttf users, then I guess we will need to come up with a different way of handling this at that point in time. Since we do not know what the font situation will exactly look like then, I don't think that speculating on this now is all that useful. So for now I'll just go with the 'ln -s $(fc-match -f "%{file}" "sans") $RPM_BUILD_ROOT%{_datadir}/%{name}/font.ttf' approach. -- You are receiving this mail because: You are on the CC list for the bug.

4 years, 1 month

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 1806272] DejaVu has been repackaged in F32+ using new fonts packaging macros; those macros use an srpm-independent file layout and remove srpm-level sharing like the previous -common subpackage

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1806272 --- Comment #26 from Nicolas Mailhot <nicolas.mailhot(a)laposte.net> --- (In reply to Hans de Goede from comment #24) > Thank you for adding the compat packages. > > I must be honest though, this is not entirely what I was expecting. I was > expecting the compat symlinks to be part of the main dejavu-sans-fonts, > dejavu-serif-fonts, etc. packages. That way they will automatically just be > there, without packages depending on say dejavu-sans-fonts needing to adjust > their Requires. https://src.fedoraproject.org/rpms/dejavu-fonts/blob/f32/f/dejavu-fonts.s... > For these games my plan is to add e.g.: > > BuildRequires: font(dejavusans) fontconfig > > To the packages and then generate the name the symlink points to using > commands like these: > > fc-match -f "%{file}" "sans" > fc-match -f "%{file}" "sans:italic" > fc-match -f "%{file}" "sans:bold" > fc-match -f "%{file}" "sans:bold:italic" > fc-match -f "%{file}" "serif" > fc-match -f "%{file}" "monospace" > > The idea here is to make things more future proof, so that we can deal with > any future font-file-path changes with just a rebuild. It will be a little more future-proof, but not as much as you think. Fonts are evolving outside the one style = one file model. Mostly, due to the influence of web fonts, because CSS uses a stacking model, identical to the one in fontconfig. Styles can now be spread over multiple files (that is already true for the Math extension of DejaVu Serif) or, on the contrary, be merged into a single file (variable fonts). And I’ve no idea when exactly the legacy model used before fontconfig will become totally incompatible with the distribution default font choices, but the movement has been accelerating, thanks to the huge amount of money Google pumped in web fonts, which is breaking the Windows fonts deadlock right now. Companies now require their design offices to create web sites and mobile apps, which forces those to drop legacy proprietary fonts for OFL fonts. You have more chance to bump into Fortune500 designers in github’s font issue trackers nowadays, than to bump into someone who knows what fontforge or Fedora are. -- You are receiving this mail because: You are on the CC list for the bug.

4 years, 1 month

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 1806272] DejaVu has been repackaged in F32+ using new fonts packaging macros; those macros use an srpm-independent file layout and remove srpm-level sharing like the previous -common subpackage

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1806272 --- Comment #25 from Hans de Goede <hdegoede(a)redhat.com> --- I've gone over the list which I posted in comment 8. From this I've come up with 2 lists which I plan to take action on once I've some feedback on the approach which I suggested in comment 24. I plan to file bugs against these packages, asking them to check if they need to adjust their package for the file-path changes and adding some example specfile bits for how this can be done in a future proof way using fc-match: xpilot-ng-data-0:4.7.3-20.fc32.noarch 0ad-data-0:0.0.23b-4.fc32.noarch wesnoth-data-0:1.15.2-2.fc32.noarch retroarch-assets-0:1.8.4-4.fc32.noarch retroarch-freeworld-assets-0:1.8.4-3.fc32.noarch neverball-neverball-0:1.6.0-20.fc32.x86_64 neverball-neverputt-0:1.6.0-20.fc32.x86_64 teeworlds-data-0:0.7.4-3.fc32.noarch foobillard-0:3.0a-33.fc32.x86_64 hedgewars-0:1.0.0-4.fc32.x86_64 gravity-beams-and-evaporating-stars-0:1.0-4.fc32.x86_64 glob2-0:0.9.4.4-49.fc32.x86_64 lincity-ng-data-0:2.9-0.20.20160605git7f266b1.fc32.noarch pioneer-data-0:20200203-1.fc32.noarch And since I maintain them (or there does not seem to be an active maintainer) I will try to take care of fixing these myself: marsshooter-data-0:0.7.6-14.fc32.noarch trackballs-0:1.1.4-36.fc32.x86_64 vodovod-0:1.10r22-15.fc32.x86_64 sumwars-data-0:0.5.8-19.fc32.noarch scorched3d-0:44-21.fc32.x86_64 enigma-0:1.21-17.20160222git0027b3b8e694.fc32.x86_64 hyperrogue-0:10.0-9.d.fc32.x86_64 Note these are all games and such these are likely all cases using direct file-paths (usually through symlinks) so these have a high likelyhood of really needing to be fixed. If you look at the list from comment 8, then you will see that there are a bunch of other packages there. If you suspect that any of the other packages need to be fixed too, then please file a bug against them for this. -- You are receiving this mail because: You are on the CC list for the bug.

4 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

i18n-bugs March 2020