[gentoo-user] e2fsck -c when bad blocks are in existing file?
I've got an SSD that's failing, and I'd like to know what files contain bad blocks so that I don't attempt to copy them to the replacement disk. According to e2fsck(8): -c This option causes e2fsck to use badblocks(8) program to do a read-only scan of the device in order to find any bad blocks. If any bad blocks are found, they are added to the bad block inode to prevent them from being allocated to a file or directory. If this option is specified twice, then the bad block scan will be done using a non-destructive read-write test. What happens when the bad block is _already_allocated_ to a file? -- Grant
Re: [gentoo-user] Re: PHP, Haru, Ghostscript, Courier, and Nimbus
Grant Edwards wrote:
>
> Nobody said anything about embedding Courier. You said the problem
> happened when the "Nimbus" font was used, so it was suggested you
> embed the "Nimbus" font.
But I don't want to use / embed the Nimbus font at all!
libharu is called by HaruDoc::getFont('Courier', 'WinAnsiEncoding')
This *does* work - the font *is* Courier when you look at the PDF.
But -
- until ghostscript 9.55, in the PDF font properties, the font
was correctly named "Courier" so that every PDF reader could
display it;
- from ghostscript 9.56, in the PDF font properties, the font
is named "Nimbus" instead of "Courier", and some PDF readers
have problems to display.
The only "Nimbus reference" I have found is a line in the file
/usr/share/ghostscript/9.56.1/Resource/Init/Fontmap.GS which reads
/Courier/NimbusMonoPS-Regular ;
but this line is the same in gs 9.55 and 9.56. So I don't understand
what/why has changed here.
BTW, I now have tried to embed truetype fonts. Seems to work
(although the character outline is thinner, overall more "pale").
File size increases from 29K to 121K - would be OK for me...
-Matt
[gentoo-user] Re: PHP, Haru, Ghostscript, Courier, and Nimbus
On 2022-11-07, Matthias Hanft wrote: > Michael wrote: >> >> If your customers do not have Nimbus fonts available on their OS/PDF viewer, >> the viewer application will proceed using font substitution. It will use >> whichever font family it thinks is the closest match, I would assume >> Helvetica. Their application appears to get confused and substitute the >> Nimbus fonts with something else. In any case, the solution to this is to >> embed the Nimbus fonts in the PDF file. > > How would I do that? It seems to be impossible for "Courier" because this > is a built-in font "and all viewers can display them", as stated at > https://durak.org/sean/pubs/software/php-7.0.0/haru.builtin.fonts.html > So it won't make much sense to embed Courier into the PDF anyway?! Nobody said anything about embedding Courier. You said the problem happened when the "Nimbus" font was used, so it was suggested you embed the "Nimbus" font.
Re: [gentoo-user] PHP, Haru, Ghostscript, Courier, and Nimbus
Michael wrote:
>
> If your customers do not have Nimbus fonts available on their OS/PDF viewer,
> the viewer application will proceed using font substitution. It will use
> whichever font family it thinks is the closest match, I would assume
> Helvetica. Their application appears to get confused and substitute the
> Nimbus fonts with something else. In any case, the solution to this is to
> embed the Nimbus fonts in the PDF file.
How would I do that? It seems to be impossible for "Courier" because this
is a built-in font "and all viewers can display them", as stated at
https://durak.org/sean/pubs/software/php-7.0.0/haru.builtin.fonts.html
So it won't make much sense to embed Courier into the PDF anyway?!
It's just that >=ghostscript-gpl-9.56 won't write the requested font name
$myFont=$myPdf->getFont('Courier', 'WinAnsiEncoding');
into the PDF, but the substituted font name "Nimbus" (which seems to
confuse some PDF readers). Why did they change it from 9.55 to 9.56?
This is strange...
To be completely independent from any PDF display software, I could imagine
that the following could help:
- install media-fonts/corefonts
- load the ttf font with embed=true:
https://durak.org/sean/pubs/software/php-7.0.0/harudoc.loadttf.html
for example,
$myFontName=$myPdf->loadTTF('/usr/share/fonts/corefonts/cour.ttf', TRUE);
$myFont=$myPdf->getFont($myFontName, 'WinAnsiEncoding');
but I guess it will blow up my nice little PDF files (29 K only!) to a
multiple size... :-(
Anyway, I'll give it a try.
-Matt
Re: [gentoo-user] PHP, Haru, Ghostscript, Courier, and Nimbus
On Monday, 7 November 2022 11:56:34 GMT Matthias Hanft wrote:
> Hi,
>
> since many years, I'm using PHP (currently 7.4) and the (self-
> compiled) Haru extension to produce PDF invoices on my server.
>
> Internally, Haru seems to use Ghostscript, because:
>
> - up to app-text/ghostscript-gpl-9.55.0-r2, when you look at the
> PDF "properties" and then the "fonts" tab, there is "Courier",
> "Helvetica" and "Helvetica-BoldOblique" - just as requested in
> my PHP script like
>$myPdf=new HaruDoc();
>[...some page settings...]
>$myFont=$myPdf->getFont('Courier', 'WinAnsiEncoding');
>
> - from app-text/ghostscript-gpl-9.56.1-r3 on, everything looks like
> before, but in the "properties/fonts" tab of the resulting PDF,
> the fonts are now "NimbusMonoPS-Regular", "NimbusSands-BoldItalic"
> and "NimbusSans-Regular".
>
> I have already found this "translation" in the file
> /usr/share/ghostscript/9.56.1/Resource/Init/Fontmap.GS but there is
> obviously no relevant difference in that file between 9.55 and 9.56.
>
> Some of my customers now seem to have trouble if the fonts in the
> PDF properties are named "Nimbus" instead of "Courier" - they just
> see some hieroglyphics when displaying the PDF.
>
> Any idea that's going wrong here?
>
> Thanks in advance,
>
> -Matt
If your customers do not have Nimbus fonts available on their OS/PDF viewer,
the viewer application will proceed using font substitution. It will use
whichever font family it thinks is the closest match, I would assume
Helvetica. Their application appears to get confused and substitute the
Nimbus fonts with something else. In any case, the solution to this is to
embed the Nimbus fonts in the PDF file.
signature.asc
Description: This is a digitally signed message part.
[gentoo-user] PHP, Haru, Ghostscript, Courier, and Nimbus
Hi,
since many years, I'm using PHP (currently 7.4) and the (self-
compiled) Haru extension to produce PDF invoices on my server.
Internally, Haru seems to use Ghostscript, because:
- up to app-text/ghostscript-gpl-9.55.0-r2, when you look at the
PDF "properties" and then the "fonts" tab, there is "Courier",
"Helvetica" and "Helvetica-BoldOblique" - just as requested in
my PHP script like
$myPdf=new HaruDoc();
[...some page settings...]
$myFont=$myPdf->getFont('Courier', 'WinAnsiEncoding');
- from app-text/ghostscript-gpl-9.56.1-r3 on, everything looks like
before, but in the "properties/fonts" tab of the resulting PDF,
the fonts are now "NimbusMonoPS-Regular", "NimbusSands-BoldItalic"
and "NimbusSans-Regular".
I have already found this "translation" in the file
/usr/share/ghostscript/9.56.1/Resource/Init/Fontmap.GS but there is
obviously no relevant difference in that file between 9.55 and 9.56.
Some of my customers now seem to have trouble if the fonts in the
PDF properties are named "Nimbus" instead of "Courier" - they just
see some hieroglyphics when displaying the PDF.
Any idea that's going wrong here?
Thanks in advance,
-Matt
