Bugzilla Bug 125253

This bug is essentially duplicate of Bug 118511, but I am filing as a new one,
because I disagree with resolution of it. It can be upstream issue, but Gentoo
should take an action and mask the 7.0.5 version. It takes over a minute to
start, such version simply cannot be marked unstable.

Besides as people report in forums,
http://forums.gentoo.org/viewtopic-t-420754-highlight-acroread.html
7.0.5 starts fast on Fedora. It seems that this is due to interaction between
fonts  on Gentoo and acroread-7.0.5. 

The point is, if this is the fourth time that this has been reported it should
not be just dissmissed as upstream issue, 7.0.5 should be masked so that more
pepole do not have to wonder what is wrong with the package.

(In reply to comment #0)
> http://forums.gentoo.org/viewtopic-t-420754-highlight-acroread.html

Hi,

I started that thread 2 months ago and today when I found your bug here, just
tried run acroread and realized, I am not able to reproduce it anymore.
Strange. It must be OK now after upgrade of some package(s), but dont know
which.

Portage 2.1_pre5-r4 (default-linux/x86/2005.1, gcc-3.4.5, glibc-2.3.5-r2,
2.6.15-ck1 i686)
=================================================================
System uname: 2.6.15-ck1 i686 AMD Athlon(tm) processor
Gentoo Base System version 1.6.14
ccache version 2.3 [disabled]
dev-lang/python:     2.4.2
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=athlon -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env
/usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config
/usr/share/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=athlon -pipe -fomit-frame-pointer"
DISTDIR="/mnt/mandrake/opt/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LANG="cs_CZ"
LDFLAGS="-Wl,-O1"
LINGUAS="cs"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://mirror.gentoo.sk/gentoo-portage"
USE="x86 3dnow X aac acpi alsa apache2 asf audiofile avi bash-completion berkdb
bitmap-fonts bzip2 cairo cdparanoia cdr crypt cups curl dbus dts dvd dvdread
emboss encode exif expat ffmpeg firefox flac flash foomaticdb fortran ftp gd
gdbm gif glut gmp gpm gstreamer gtk gtk2 hal iconv icq idn imagemagick imlib
jabber java jpeg kde kdeenablefinal lcms libg++ libwww mad maildir mbox mikmod
mime mmx mng motif moznoirc moznomail mozsvg mp3 mpeg msn musepack mysql nas
ncurses nls nptl nptlonly nsplugin nvidia ogg oggvorbis openal opengl oss pam
pcre pdflib perl php pic png python qt quicktime readline recode ruby sdl slang
sndfile speex spell ssl svg tcltk tcpd theora tiff truetype truetype-fonts
type1-fonts usb vorbis win32codecs wma xine xml xml2 xosd xprint xv xvid zlib
elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux linguas_cs
userland_GNU video_cards_nvidia"
Unset:  ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LC_ALL

My system is fully up to date with stable (x86), but acroread just starts very
slow and I see 100% CPU utilization.  
Did you use any of the hacks suggested in the forums thread? 
Or did you install some ~x86 package in meantime?

Portage 2.0.54 (default-linux/x86/2005.0, gcc-3.4.5, glibc-2.3.5-r2, 2.6.14-ck5
i686)
=================================================================
System uname: 2.6.14-ck5 i686 AMD Athlon(TM) XP 2400+
Gentoo Base System version 1.6.14
dev-lang/python:     2.4.2
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/lib/X11/xkb /u
sr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/
/usr/sha
re/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/
/usr/share/texmf/tex/platex/
config/ /usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://128.213.5.34/gentoo/ http://mirror.datapipe.net/gentoo
ftp://mirr
ors.sec.informatik.tu-darmstadt.de/gentoo/
ftp://ftp.ussg.iu.edu/pub/linux/gentoo"
LANG="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 3dnow 3dnowext X aac aalib alsa apm artworkextra audiofile avi
bash-completion 
berkdb bitmap-fonts bzip2 cdparanoia cdr cjk cpudetection crypt cups curl
custom-cflags 
dbus divx4linux dts dv dvb edl eds emboss encode exif expat fam fbcon fbdev
fftw firefox
 flac foomaticdb fortran fpx gd gdbm gif gimp glibc-omitfp glut gnome gphoto2
gpm graphv
iz gstreamer gtk gtk2 gtkhtml guile hal idn imagemagick imlib ipv6 java
javascript jpeg 
lcms libcaca libg++ libwww live lzo lzw-tiff mad mikmod mmx mmxext mng motif
mozilla moz
svg mp3 mpeg msn nas ncurses network new-login nls nptl nptlonly nsplugin
nvidia ogg ogg
vorbis openal opengl pam pdflib perl plotutils png python quicktime readline
real recode
 rtc scanner sdl slang spell sse ssl svg tcltk tcpd tetex theora tiff truetype
truetype-
fonts type1-fonts udev unicode usb v4l v4l2 vorbis win32codecs wmf xml2 xmms xv
xvid zli
b userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LDFLAGS, LINGUAS, MAKEOPTS

(In reply to comment #2)
> Did you use any of the hacks suggested in the forums thread? 
> Or did you install some ~x86 package in meantime?

Although I have x86 in make.conf, I have also big package.keyword file -
xorg-x11-7, gtk+, kde and few days also freetype (among other). Its two months
and "genlop -l" would be really long since 8.1.2006. 

Before, I tried only hack with UnixFnt07.lst file in my ~/.adobe, but I deleted
this directory today and without this it is starting perfectly like before
(7.0.1.1). I am never doing someting like changing permissions, editing scripts
and so in /usr /opt and other system directories. I 

I added a fix for this one as -r2, please upgrade and tell me if it helps.

-r2 fixes my issue, but I had to remove ~/.acroread first. 
This should be probably mentioned in pkg_postinst, that it is recommended to
remove the directory. Thanks for the fix. Please make -r2 stable ASAP.

As I've noted in the forum, the patch in -r2 does *not* fix the issue on my
machine. But as also recently noted on the forum, there is a solution which
does: modifying fonts.conf so that it doesn't include the thousands and
thousands of bitmap fonts in /usr/share/fonts, /usr/X11R6/lib/X11/fonts/75dpi,
and /usr/X11R6/lib/X11/fonts/100dpi (the latter two being redundant since
/usr/X11R6/lib/X11/fonts is just a symlink to /usr/share/fonts).

Given that the patch does *not* work for everyone (for reasons that escape me),
I'm inclined to suggest that this bug is not in fact resolved, and that the
patch is actually a workaround for a more problematic issue with the way
/etc/fonts/fonts.conf is installed by default on Gentoo machines.

I reported the fontconfig problem as Bug #125529.

the patch in -r2 does *not* fix the issue on my machine too, 

acroread-7.0.1.1 work fast please mask acroread-7.0.5* until you fix the font
problem or the patch works on every machine,

thanks
Nicola

(In reply to comment #8)
> the patch in -r2 does *not* fix the issue on my machine too, 
> 
> acroread-7.0.1.1 work fast please mask acroread-7.0.5* until you fix the font
> problem or the patch works on every machine,
> 
> thanks
> Nicola
> 
Until today I thought the patch in -r2 does fix the issue for me, but today I
tried acroread on another machine (a colleagues personal workstation instead
of our main server) and it took 2 minutes to start. Since we have
acroread-7.0.5-r2 on both machines I looked for the difference that may cause
this. I soon found that on the main server I did a "emerge -e system" after the
late gcc-upgrade (which besides many others rebuild fontconfig and xorg-x11)
but not on the workstation. So I tried this:
emerge -p fontconfig

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild   R   ] media-libs/fontconfig-2.2.3
emerge fontconfig
fc-cache -f -v
fc-cache: "/usr/X11R6/lib/X11/fonts/Type1": caching, 29 fonts, 0 dirs
...
fc-cache: succeeded

After this acroread starts in about 6 seconds (a Pentium III with 256 MB RAM).

This solved thanks Horst

(In reply to comment #10)

Are you sure that this really fixed anything for you?

My experience has been that acroread takes some 20+ seconds on my machine to
start after the reboot, but only ~1 second if started again (Pentium M, 512 MB
RAM).  The damn thing just seems to open tons of files, and Linux block caching
helps a lot.

So, could you reboot your machine (or at the very least read lots of data from
disk, say 2*physical memory size) and check again?

BTW, after I left only directories with scalable fonts in
/etc/fonts/fonts.cache, -r2 in fact takes some 5 second *longer* to start for
me than -r1, as -r2 reads all the font files, whereas -r1 is fine with just
reading the cache file.

(In reply to comment #11)

You're right! The first acroread I started this morning again needed 2 minutes
(The overnight backup "cleaned" the block cache.). The next ones start fast
(6 seconds). But I surely had to do
  emerge fontconfig
  fc-cache -f -v
to get this behavior. Before that I could start one acroread after another and
always had to wait the 2 minutes.

That also explains why on our main server (many users and 4GB RAM, so a high
chance that the relevant files are in the block cache) I always had a fast
starting acroread.