No, this is not a report of essential changes needed. In fact, no changes to Puppy are needed at all. This is just an update on my previous post.

npierce wrote:

But I'm having problems with some fonts.

Cyrillic works:

Code:

xmessage "АаБбВвГгЃѓВвДдЂђЅѕЏџЕеЄє"

but Greek does not:

Code:

xmessage "ΑαΒβΓγΔδΕεΖζΗηΘθΙιΚκΛλΜμ"

Greek works now.

It is no surprise that this was a simple matter of a missing font. But the matter of why the font was missing was more complex.

Racy comes with a couple of iso10646-1 (Unicode) encoded fonts, which contain glyphs for many languages including Greek. Most applications have no trouble finding those glyphs, why does xmessage?

xmessage uses the Athena widget set (Xaw) and the X Toolkit (Xt). Thinking that perhaps Xaw needed a simple bitmapped font instead of the existing scalable Type1 and TTF fonts, I downloaded a bitmapped iso10646-1 font. It did not help.

Then I noticed that characters that were displayed instead of the Greek characters had codes that were totally unrelated to Unicode, but they exactly matched the codes for the old 8-bit iso8859-7 (Greek) encoding. So even though I was supplying Unicode text (in its UTF-8 flavor), Xaw or Xt was apparently converting this to 8-bit iso8859-7 and failing because I had no iso8859-7 encoded font. The nice modern iso10646-1 encoded fonts were ignored.

Installing an iso8859-7 encoded font solved the problem.

But that leads to another question:

X has the ability to re-encode fonts so that a font with glyphs mapped in one encoding can be re-encoded for a different encoding. This includes the ability to re-encode an iso10646-1 font to various iso8859-* fonts, as long as all of the necessary glyphs are available.

A look at fonts.scale or fonts.dir in /usr/share/fonts/default/TTF (or /usr/share/X11/fonts/TTF/ , which is a link to it) will show you that the single DejaVuSans.ttf font can be used for 8859-1, -2, -3, -4, -5, -8, -9, -10, -15, iso10646-1, koi8-e, -r, -ru, -u, and -uni. Essentially it does the work of what once would have required fifteen files. (This helps keep our Puppies lean and trim.)

Note, however, that iso8859-7 is not among those fifteen encodings listed. Since we know that DejaVuSans.ttf has the glyphs for iso8859-7, the question is: why is that encoding not listed in fonts.scale and fonts.dir?

The fonts.scale file is created by the mkfontscale utility. The fonts.dir file is created by the mkfontdir utility, which gets its list of scalable fonts from fonts.scale. The mkfontscale utility will not generate an entry for an 8-bit encoding when one or more of its glyphs is missing from the font file it would be re-encoded from.

Are there any iso8859-7 glyphs missing from Puppy's iso10646-1 "DejaVu Sans" font files? No. But mkfontscale thinks one is missing.

I traced the problem to a bug in the libfontenc library. iso8859-7 defines no character for cell 0xd2, but the function in libfontenc that re-encodes iso10646-1 to iso8859-7 mistakenly believes that there should be a character there. So when mkfontscale finds no glyph for it in the font, it assumes that a glyph is missing, and so doesn't add an entry for iso8859-7 to fonts.scale. In turn, mkfontdir doesn't add an entry to fonts.dir.

There is a similar bug in libfontenc for the iso8859-6 (Arabic) encoding.

I have reported these two bugs to Alan Coopersmith, a maintainer of libfontenc. Perhaps a future version of this library will allow the font.scale and font.dir files to properly include entries for Greek and Arabic re-encoded fonts.

In the meantime, if any Wary/Racy user needs an 8-bit Greek version of the DejaVuSans fonts, she may manually add these entries to both the fonts.scale and fonts.dir files in the /usr/share/fonts/default/TTF/ directory:

(Note that there are only four lines there, although your browser may have wrapped them if you have a small window.)

After adding those lines, run this command to make your X server aware of them:

Code:

xset fp rehash

Reminder: most applications will happily find the iso10646-1 (Unicode) encoding for fonts. You would only need to do all the above if you needed a Greek font for an application that only supported the old 8-bit encodings.

If you need an 8-bit Arabic version of the DejaVuSans fonts, you may add these two entries to both of the files mentioned above:

There are only two entries here because the oblique and bold-oblique files are each missing an Arabic glyph, so are invalid.

IMPORTANT: If you make any of these changes and later rerun mkfontscale and mkfontdir in the /usr/share/fonts/default/TTF/ directory, as you would if you were installing new fonts, it will overwrite your changes. You might want to keep a file containing only the lines you have added so that you can later merge it with the overwritten files after you install any new fonts. (With luck, libfontenc will have been fixed by then and you won't need to. )

I don't recommend trying this trick with the "nimbus" fonts in the /usr/share/fonts/default/Type1/ directory. I've not looked at all those fonts, but the n019003l.pfb file was missing at least one glyph for each of the iso8859-7 and iso8859-6 encodings.

I have installed Racy 5.2.90 on my AMD LE 1250 box and chose German locale in the Quick Setup but I accidentally did not tick UTF-8 Encoding. I changed this later in Puppy-Setup, but it doesn't get permanent. So on every reboot I have to change to UTF-8 again.
Is there something wrong?
Thanks for a hint.

Yes, there is something wrong, I have been trying to reproduce this in a similiar way.

I don´t think this is specific to German.
Other languages, please test: changing to/from utf-8

Hope this will help locating the bug

I am not having any problem.

Running as a German user, I used quickcountry (symlink to quicksetup) to untick and tick the UTF-8 checkbox. There was no problem.

The problem may occur if you altered the initrd.gz the first time, to say de_DE-UTF-8, then that will be used at a reboot. QuickCountry/QuickSetup will offer to change the initrd.gz if you change the UTF-8 checkbox.

I like to confirm:
No problem if the offer to change initrd.gz is accepted !

Example: Change from de_AT to de_AT.utf8 only permanent if changed initrd.gz.

This leads to the idea:
I have decided wrong and LaRioja has decided wrong.
Why ask the user?
Always change it please without asking

edit:
I have run xorgwizard without utf8, our (shinobar´s) trick OUTPUT_CHARSET=UTF-8 did not work in console

this is leading to the next ( old ) idea:
make utf8 default without exceptions for non English

However, yes, it would probably be better to set UTF-8 as default for non-English. I can see some issues with doing that though, so will leave it until after Wary/Racy 5.3-final. Everything is frozen for now._________________http://barryk.org/news/

No, this is not a report of essential changes needed. In fact, no changes to Puppy are needed at all. This is just an update on my previous post.

npierce wrote:

But I'm having problems with some fonts.

Cyrillic works:

Code:

xmessage "АаБбВвГгЃѓВвДдЂђЅѕЏџЕеЄє"

but Greek does not:

Code:

xmessage "ΑαΒβΓγΔδΕεΖζΗηΘθΙιΚκΛλΜμ"

Greek works now.

It is no surprise that this was a simple matter of a missing font. But the matter of why the font was missing was more complex.

Racy comes with a couple of iso10646-1 (Unicode) encoded fonts, which contain glyphs for many languages including Greek. Most applications have no trouble finding those glyphs, why does xmessage?

xmessage uses the Athena widget set (Xaw) and the X Toolkit (Xt). Thinking that perhaps Xaw needed a simple bitmapped font instead of the existing scalable Type1 and TTF fonts, I downloaded a bitmapped iso10646-1 font. It did not help.

Then I noticed that characters that were displayed instead of the Greek characters had codes that were totally unrelated to Unicode, but they exactly matched the codes for the old 8-bit iso8859-7 (Greek) encoding. So even though I was supplying Unicode text (in its UTF-8 flavor), Xaw or Xt was apparently converting this to 8-bit iso8859-7 and failing because I had no iso8859-7 encoded font. The nice modern iso10646-1 encoded fonts were ignored.

Installing an iso8859-7 encoded font solved the problem.

But that leads to another question:

X has the ability to re-encode fonts so that a font with glyphs mapped in one encoding can be re-encoded for a different encoding. This includes the ability to re-encode an iso10646-1 font to various iso8859-* fonts, as long as all of the necessary glyphs are available.

A look at fonts.scale or fonts.dir in /usr/share/fonts/default/TTF (or /usr/share/X11/fonts/TTF/ , which is a link to it) will show you that the single DejaVuSans.ttf font can be used for 8859-1, -2, -3, -4, -5, -8, -9, -10, -15, iso10646-1, koi8-e, -r, -ru, -u, and -uni. Essentially it does the work of what once would have required fifteen files. (This helps keep our Puppies lean and trim.)

Note, however, that iso8859-7 is not among those fifteen encodings listed. Since we know that DejaVuSans.ttf has the glyphs for iso8859-7, the question is: why is that encoding not listed in fonts.scale and fonts.dir?

The fonts.scale file is created by the mkfontscale utility. The fonts.dir file is created by the mkfontdir utility, which gets its list of scalable fonts from fonts.scale. The mkfontscale utility will not generate an entry for an 8-bit encoding when one or more of its glyphs is missing from the font file it would be re-encoded from.

Are there any iso8859-7 glyphs missing from Puppy's iso10646-1 "DejaVu Sans" font files? No. But mkfontscale thinks one is missing.

I traced the problem to a bug in the libfontenc library. iso8859-7 defines no character for cell 0xd2, but the function in libfontenc that re-encodes iso10646-1 to iso8859-7 mistakenly believes that there should be a character there. So when mkfontscale finds no glyph for it in the font, it assumes that a glyph is missing, and so doesn't add an entry for iso8859-7 to fonts.scale. In turn, mkfontdir doesn't add an entry to fonts.dir.

There is a similar bug in libfontenc for the iso8859-6 (Arabic) encoding.

I have reported these two bugs to Alan Coopersmith, a maintainer of libfontenc. Perhaps a future version of this library will allow the font.scale and font.dir files to properly include entries for Greek and Arabic re-encoded fonts.

In the meantime, if any Wary/Racy user needs an 8-bit Greek version of the DejaVuSans fonts, she may manually add these entries to both the fonts.scale and fonts.dir files in the /usr/share/fonts/default/TTF/ directory:

(Note that there are only four lines there, although your browser may have wrapped them if you have a small window.)

After adding those lines, run this command to make your X server aware of them:

Code:

xset fp rehash

Reminder: most applications will happily find the iso10646-1 (Unicode) encoding for fonts. You would only need to do all the above if you needed a Greek font for an application that only supported the old 8-bit encodings.

If you need an 8-bit Arabic version of the DejaVuSans fonts, you may add these two entries to both of the files mentioned above:

There are only two entries here because the oblique and bold-oblique files are each missing an Arabic glyph, so are invalid.

IMPORTANT: If you make any of these changes and later rerun mkfontscale and mkfontdir in the /usr/share/fonts/default/TTF/ directory, as you would if you were installing new fonts, it will overwrite your changes. You might want to keep a file containing only the lines you have added so that you can later merge it with the overwritten files after you install any new fonts. (With luck, libfontenc will have been fixed by then and you won't need to. )

I don't recommend trying this trick with the "nimbus" fonts in the /usr/share/fonts/default/Type1/ directory. I've not looked at all those fonts, but the n019003l.pfb file was missing at least one glyph for each of the iso8859-7 and iso8859-6 encodings.

Wow, that is fantastic detective work!

This is something to think about for Woof later on, after 5.3-final is out._________________http://barryk.org/news/

Ran Racy all day without a hitch using WiFi... went to shutdown this evening, and Racy 'HUNG' on the shutdown just before updating the savefile. After 10-minutes I knew a shutdown wouldn't happen so was forced to do 'push and hold power button on computer' to shutdown.

Upon trying to reboot with Racy, all that I get is:

ext2-fs (loop): error: ext2 lookup: deleted inode reference: 16451

and it goes on and on through a bunch of numbers after that so am forced to shutdow with power button again...

Hope It can be recovered?

Bummer BK! and just when I thought Racy was really doing a fantastic job.

I have tried several times on the IBM ThinkPad X30 and Flashplayer 11.2.202.228 does not work.
Checking the <http://www.adobe.com/software/flash/about/> no player detected.

Flashplayer 11.1.102.63 works works with racy5291.

--BUT--

On the Acer TravelMate 4670 Flashplayer 11.2.202.228 works with racy5291.

What CPU does the Thinkpad X30 have?

There have been issues with the Adobe player requiring a machine-language instruction that is not in an older CPU.

This is an awkward situation. I have added a warning, after the player is downloaded, that if it doesn't work, try an older one -- a PET in the Puppy Package Manager._________________http://barryk.org/news/

I have spent the last 24 hours trying to get the latest flashplayer working on an old Acer Aspire 1350 laptop. It just doesn't work on this machine. The last version to work is 10.1.102.63._________________Classic Opera 12.16 browser SFS package for Precise, Slacko, Racy, Wary, Lucid, etc available here

So went back and did a complete pfix=purge and was able to load 5-2.91 but... ' With Errors.' After load, could never config Internet connection. It did shutdown with a savefile but... also with 'With Errors'.)

I am kind of suspecting that something went screwy with the Internet part of 5-2.91... that was the first time I used WiFi for a session, all previous sessions were with eth0.

It's not a big deal on my part as I have many puppy versions running for tests that I can recover any files with, but, this is why I like to test all the popular puppy's, make them more reliable and better for the new users so they don't encounter these types of things. Hopefully someone will find the reason for the error and if it's a bug, BK can correct it.

Usually, you have to give the complete path, viz:
fsck /dev/sda1 - which is sufficient for an ext2 partition.
Then, it will come up with a warning that dire things may happen and you have to make your final decision.
The fsck command is contained in amost every distro. Sometimes I run it from a 'foreign' liveCD, using pfix=ram, of course, if it's another Puppy variant. Despite the warnings, it has always worked for me, unless there is something else wrong, like bad sectors!

fsck -f /dev/sdb1 yes it always works and then one day it finds something and you cross your fingers that your latest backup is ok because what you get when something is badly wrong will take you a month or two to sort if you could be bothered. i still do it naked though because i havent got any thing much to lose and even that nothingness that is multiple backed up off line._________________
ASUS EeePC Flare series 1025C 4x Intel Atom N2800 @ 1.86GHz RAM 2063MB 800x600p ATA 320G
_-¤-_<º))))><.¸¸.•´¯`•.#.•´¯`•.¸¸. ><((((º>

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum