Bug 432683

Created attachment 294831 [details]
graph_legend.png from i386 build

Created attachment 294832 [details]
graph_legend.png from x86_64 build

Please note, that this is NOT only a timestamp problem, the timestamp thing
is easy to eliminate, but doesn't solve this difference.

Can we get rid of that one as well? AFAIK doxygen saw no rebuild for gcc 4.3
as well...

Robert, 1.5.5 is built against fcc-4.3 in rawhide. Please reopen it again if 
the bug still exists. Thanks

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.

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

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.

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.

Is this really a bug?    Visually the two graphs are close enough.   Why are
they being bitwise compared?

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.

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. 

The interesting thing is by the way, that it works on Fedora 8 while it does not 
on Rawhide.

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? 

(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.

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"

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?

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.

$ ./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

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.

Created attachment 295501 [details]
image showing the difference between graph_lengend.png generated on i386 and x86_64

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.

That patch is included in graphviz-2.16.1-0.4.fc9, which hit Rawhide yesterday.
 Good to close?

Moving off beta list.

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

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.

Sorry, looks as my mock cache was not up2date. Works for me so far. Thank you
and closing now.