Bug 432683 - Doxygen causes slightly different images on i386 and x86_64
Doxygen causes slightly different images on i386 and x86_64
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: graphviz (Show other bugs)
rawhide
All Linux
low Severity urgent
: ---
: ---
Assigned To: Jima
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: F9Target 342921
  Show dependency treegraph
 
Reported: 2008-02-13 15:30 EST by Robert Scheck
Modified: 2009-07-30 16:55 EDT (History)
2 users (show)

See Also:
Fixed In Version: 2.16.1-0.4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-25 12:21:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
graph_legend.png from i386 build (20.00 KB, image/png)
2008-02-13 15:32 EST, Robert Scheck
no flags Details
graph_legend.png from x86_64 build (20.13 KB, image/png)
2008-02-13 15:33 EST, Robert Scheck
no flags Details
the result of diffimg (white where any pixel in the two images is different) (2.24 KB, image/png)
2008-02-18 21:51 EST, John Ellson
no flags Details
image showing the difference between graph_lengend.png generated on i386 and x86_64 (1.96 KB, image/png)
2008-02-21 07:32 EST, John Ellson
no flags Details
patch to graphviz to fix multilib issue (1.14 KB, patch)
2008-02-21 08:18 EST, John Ellson
no flags Details | Diff

  None (edit)
Description Robert Scheck 2008-02-13 15:30:07 EST
Description of problem:
Doxygen causes slightly different images on i386 and x86_64 for popt (just 
rebuild latest popt from Rawhide, e.g. popt-1.13-1). When trying to rebuild
for gcc 4.3, I've the following result:

# ./multilib-cmp.py popt-devel-1.13-2.fc9.i386.rpm popt-devel-1.13-
2.fc9.x86_64.rpm
File conflict for /usr/share/doc/popt-devel-1.13/html/graph_legend.png in popt-
devel-1.13-2.fc9
#

Ouch?!

Version-Release number of selected component (if applicable):
doxygen-1.5.4-1

How reproducible:
Everytime.

Actual results:
Doxygen causes slightly different images on i386 and x86_64

Expected results:
Working stuff and same image like in the past...

Additional info:
I'll attach graph_legend.png, so that you can see the strange difference.
Comment 1 Robert Scheck 2008-02-13 15:32:57 EST
Created attachment 294831 [details]
graph_legend.png from i386 build
Comment 2 Robert Scheck 2008-02-13 15:33:12 EST
Created attachment 294832 [details]
graph_legend.png from x86_64 build
Comment 3 Robert Scheck 2008-02-13 15:35:56 EST
Please note, that this is NOT only a timestamp problem, the timestamp thing
is easy to eliminate, but doesn't solve this difference.
Comment 4 Robert Scheck 2008-02-14 16:18:47 EST
Can we get rid of that one as well? AFAIK doxygen saw no rebuild for gcc 4.3
as well...
Comment 5 Ngo Than 2008-02-15 09:02:46 EST
Robert, 1.5.5 is built against fcc-4.3 in rawhide. Please reopen it again if 
the bug still exists. Thanks
Comment 6 Robert Scheck 2008-02-15 15:58:15 EST
I'm still seeing exactly the same with 1.5.5 from Rawhide. So
http://koji.fedoraproject.org/koji/taskinfo?taskID=430312 is the
build I tried. Looks like something changed, because on F8 it is
just working as expected.
Comment 7 Ngo Than 2008-02-18 13:13:22 EST
doxygen is built with dot support, it uses dot, that is part of graphviz, as 
backend to create image files. In your case dot creates different images on 
different arch! I reassign it to correct component
Comment 8 Jima 2008-02-18 18:13:01 EST
Cc'ing John Ellson, graphviz upstream.

Any idea on this?  I'm out of the office today, but I'll take a look at things
tomorrow.
Comment 9 John Ellson 2008-02-18 21:51:50 EST
Created attachment 295230 [details]
the result of diffimg (white where any pixel in the two images is different)

The nodes have moved, so I think dot must be getting different text-extents
from pango layout.   You could modify Doxyfile to save the .dot input graphs.
Check that they are the same.	Try "dot -v xxx.dot" to see if it gets the same
fonts.
Compare the outputs of the two dot runs.
Comment 10 John Ellson 2008-02-18 21:54:15 EST
Is this really a bug?    Visually the two graphs are close enough.   Why are
they being bitwise compared?
Comment 11 John Ellson 2008-02-18 22:43:15 EST
This is not the whole story, but its part of the problem:

On x86_64 rawhide:
    $ fc-match sans
    Vera.ttf: "Bitstream Vera Sans" "Roman"

On i386 rawhide:
    $ fc-match sans
    DejaVuSans.ttf: "DejaVu Sans" "Book"

On both systems:
    $ yum list 'dejavu*' 'bitstream*'
    bitstream-vera-fonts.noarch              1.10-8             installed       
    dejavu-fonts.noarch                      2.23-1.fc9         installed       
    dejavu-fonts-experimental.noarch         2.23-1.fc9         installed       
    dejavu-lgc-fonts.noarch                  2.23-1.fc9         installed

Basically, fontconfig is inexact and unpredictable.

If anyone knows how to tell pango to use one specific font file, please let me know.
Comment 12 Robert Scheck 2008-02-19 10:03:05 EST
This two graphs are looking very closely to each other, but they're different 
images with different sizes etc, so this causes a real multilib issue. 
Comment 13 Robert Scheck 2008-02-19 10:03:27 EST
The interesting thing is by the way, that it works on Fedora 8 while it does not 
on Rawhide.
Comment 14 John Ellson 2008-02-19 17:34:30 EST
Re #12. Then perhaps docs should be a separate -noarch package?  Or perhaps
these docs could be on a website and not in the distribution?

Re #13. Yes, repeating the experiment in #11 on fc8 produces:
              DejaVuSans.ttf: "DejaVu Sans" "Book"
in both cases.   Is that what you meant? 
If we can verify that doxygen's font selection results in different fonts
then perhaps this "bug" can be blamed on fontconfig? 
Comment 15 Robert Scheck 2008-02-19 17:44:45 EST
(In reply to comment #14)
> Re #12. Then perhaps docs should be a separate -noarch package?  Or perhaps
> these docs could be on a website and not in the distribution?

Because some guys doing the Fedora Packaging review are always poking 
(forcing?) the packagers to use doxygen, graphviz and crap? And from my
personal point of view, I would have removed though things already from
everywhere. Who needs documentation when source is there?</ironic>

> Re #13. Yes, repeating the experiment in #11 on fc8 produces:
>               DejaVuSans.ttf: "DejaVu Sans" "Book"
> in both cases.   Is that what you meant? 
> If we can verify that doxygen's font selection results in different fonts
> then perhaps this "bug" can be blamed on fontconfig? 

Looks like. So if these different fonts are causing the different results, 
blame whatever is needed as long as it helps to get this issue solved. I just
want to see the same result as in Fedora 8: Same images without a separate
docs package or other even more ugly hacks. And as it was working already, I
am treating the current behaviour in Rawhide as a regression.
Comment 16 John Ellson 2008-02-19 19:29:33 EST
OK, I reported the fontconfig issue in Bug #433559, but I think the problem here
is not really fontconfig.    I'm guessing that one of the build platforms has
freefont installed, and the other does not?

doxygen uses FreeSans, which is provided exactly by freefont.
Without freefont it resolves to sans from either dejavu or bitstream, but they
produce identical results.  However, the results from sans and freesans are
different.

Suggested fix:  doxygen should add a "Requires: freefont"

Optional additional fix:  popt could add a "BuildRequires: freefont"
Comment 17 Robert Scheck 2008-02-20 16:10:40 EST
Nope, such a buildrequires doesn't solve the problem, see
http://koji.fedoraproject.org/koji/buildinfo?buildID=38018
The rebuild was because of a segfault, but I just tried
this as well...no success. What did I do wrong?
Comment 18 John Ellson 2008-02-20 19:30:39 EST
How do I see the problem now?

I just installed the koji rpms on Rawhide:

   rpm -Uvh popt-1.13-3.fc9.i386.rpm popt-1.13-3.fc9.x86_64.rpm
popt-devel-1.13-3.fc9.i386.rpm popt-devel-1.13-3.fc9.x86_64.rpm

and they installed without conflicts for me.
Comment 19 Robert Scheck 2008-02-21 03:40:05 EST
$ ./multilib-cmp.py popt-devel-1.13-3.fc9.i386.rpm popt-devel-1.13-
3.fc9.x86_64.rpm
File conflict for /usr/share/doc/popt-devel-1.13/html/graph_legend.png in popt-
devel-1.13-3.fc9
$ 

http://katzj.fedorapeople.org/multilib-cmp.py
Comment 20 John Ellson 2008-02-21 07:30:26 EST
A status update.  The conflict is now in just one image, not the many that were
conflicting before.   I can reproduce the different images locally, and the
difference is no longer caused by the font.  I suspect a much deeper rounding
issue in the dot layout engine that isn't easy to track down.
Comment 21 John Ellson 2008-02-21 07:32:22 EST
Created attachment 295501 [details]
image showing the difference between graph_lengend.png generated on i386 and x86_64
Comment 22 John Ellson 2008-02-21 08:18:26 EST
Created attachment 295503 [details]
patch to graphviz to fix multilib issue

This patch rounds the paragraph size metrics to integer points.

This patch has been applied upstream and has been tested against the popt-devel
rpms.
Comment 23 Jima 2008-03-05 09:38:27 EST
That patch is included in graphviz-2.16.1-0.4.fc9, which hit Rawhide yesterday.
 Good to close?
Comment 24 Jesse Keating 2008-03-12 11:10:34 EDT
Moving off beta list.
Comment 25 Bug Zapper 2008-05-14 01:10:47 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 26 Robert Scheck 2008-05-22 16:23:06 EDT
Sorry, I can't see any fix when using graphviz-2.16.1-0.4.fc9 and rebuilding 
popt package again, graph_legend.png graphics are still different.
Comment 27 Robert Scheck 2008-05-25 12:21:13 EDT
Sorry, looks as my mock cache was not up2date. Works for me so far. Thank you
and closing now.

Note You need to log in before you can comment on or make changes to this bug.