[Solved] Font problem with Adobe Reader 9.4.7

[ahz]

After installing AdbeRdr9.4.7-1_i486linux_enu.bin (KDE desktop) and starting acroread you get only blank squares instead of a readable font (an other application that shows the same behaviour is seamonkey-1.19 - sigh i need it for some reasons). A solution is posted here (small script at the bottom of the thread):

http://www.linuxquestions.org/questions ... -a-819115/

After invoking this script everything runs fine. Can it be integrated into one of the next Porteus editions?

Thanks!

[fanthom]

@ahz
these commands are included in rc.M already but run only when other than /base/00* modules are found (to speed up booting process).
please convert AdbeRdr9.4.7-1_i486linux_enu.bin to native xzm module and problem will be sorted.

on the other hand: if you are saving changes then Porteus may act the same way as Slackware. you dont have to convert packages to xzm and just install them with 'installpkg' utility. Slackware .txz packages contains 'doinst.sh' script which runs all necessary commands during installation.

i guess that the problem is that you have used non Slackware package (doinst.sh never operated) and you also did not convert it to xzm (rc.M was unable to spot new module). that's why got the squares and had to invoke these commands manually to solve the problem.

Please avoid non slackware packages or at least convert everything to xzm.

[ahz]

Thanks for the advices. Now I have done the following:

1. I have taken a well-working Acroread xzm-module (that I build for 32 bit Porteus from the .bin file) and bootet it with Porteus 64 bit (Always Fresh mode). After starting acroread the squares appear again
2. Take an acroread txz-module (Version 9.4.2) that is available in the net, converted it to xzm and booted again with 64 bit Porteus. You can see the squares too.

Now I am little bit confused about this...

[fanthom]

@ahz

i have found that update function from rc.M update caches but with 64bit paths and not 32bit (which is understandable).

this is how i got it to work:
1) downloaded and converted to xzm
http://repository.slacky.eu/slackware-1 ... 86-2sl.txz
http://repository.slacky.eu/slackware64 ... 64-1sl.txz
2) copied following cache files from 32bit Porteus edition to remastered compat32-libraries module:

Code: Select all

/etc/pango/i486-slackware-linux/pango.modules

it wont harm to copy also other caches to compat32-libraries (just in case):

Code: Select all

/etc/gtk-2.0/i486-slackware-linux/gtk.immodules
/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache
/usr/lib/gio/modules/giomodule.cache

please follow my advices and all should be ok then

[ahz]

Hmmm..., didn't work for me. It looks like something is deleting or overwrting /etc/pango/i486-slackware-linux/pango.modules that I copied from 32 Bit Porteus to compat32-libraries (size of this file is always 0 Bytes after booting but should be around 3500 when I compare it with the content of the compat232-module). Same seems to happen with /etc/gtk-2.0/i486-slackware-linux/gtk.immodules. Only /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache is alive. /usr/lib/gio/modules/giomodule.cache is not available in my Porteus 32 Bit.

[fanthom]

@ahz
took me a while but finally i have found the reason

please unpack compat32-libraries and create missing libstdc++.so.6 symlink manually (have no idea why it's missing as libstdc++.so.5 and libstdc++.so.4 are there)

Code: Select all

cd unpacked_xzm/usr/lib
ln -sf libstdc++.so.6.0.14 libstdc++.so.6

must be ok now.

[ahz]

Conclusion:

It is enough to create the symbolic link. No further copying files from Porteus 32 Bit is necessary. Thanks to fanthom for sorting this out!

[Hamza]

It's an ugly cheat!

[tome]

What should I change to automatically execute this (only) if 'compat32-libraries' module is activated:

Code: Select all

# These GTK+/pango files need to be kept up to date for
# proper input method, pixbuf loaders, and font support.
if [ -x /usr/bin/update-gtk-immodules ]; then
  /usr/bin/update-gtk-immodules --verbose
fi
if [ -x /usr/bin/update-gdk-pixbuf-loaders ]; then
  /usr/bin/update-gdk-pixbuf-loaders --verbose
fi
if [ -x /usr/bin/update-pango-querymodules ]; then
  /usr/bin/update-pango-querymodules --verbose
fi

Will be this bug solved for Porteus v3.0?

[fanthom]

@tome
not sure if i understand.
you want to not update the caches when compat32-libs is activated - is it?
if yes then please modify /opt/porteus-scripts/xorg/aufs-insert as follows:

Code: Select all

# Check for certain files to update system caches if necessary:
test -e /mnt/live/memory/images/compat32-libs* && exit 0
touch /mnt/live/tmp/caches/ldconfig

Will be this bug solved for Porteus v3.0?

i believe so as multilib environment is covered in aufs-insert/remove scripts:

Code: Select all

# Multilib support for x86_64 arch:
if [ $lib = lib64 ]; then
    [ -e $MOD/usr/lib/gtk-2.0/*/immodules ] && touch /mnt/live/tmp/caches/immodules
    [ -e $MOD/usr/lib/gtk-3.0/*/immodules ] && touch /mnt/live/tmp/caches/immodules
    [ -e $MOD/usr/lib/gdk-pixbuf-*/*/loaders ] && touch /mnt/live/tmp/caches/pixbuf
    [ -e $MOD/usr/lib/pango/*/modules ] && touch /mnt/live/tmp/caches/pango
fi

mind /usr/lib (and not /usr/lib64) paths.

[tome]

Ok. thanks fanthom, I will try later.

not sure if i understand

I want have letters instead of squares for some 32bit programs (Adobe Reader, Firefox) - Porteus doesn't solve this automatically after activating compat32-libraries - I must manually execute

Code: Select all

/usr/bin/update-pango-querymodules

.

[fanthom]

ok - i reread your post and the answer is 'yes', this bug is closed in porteus-3.0