GNOME Bugzilla – Bug 494736
Nth root not displayed in .dvi files
Last modified: 2010-11-08 18:19:11 UTC
I created a latex file containing 3rd roots and generated a dvi file. Evince doesnt show the 3rd roots, instead displays only square roots. Opening the file in xdvi works as expected.
Created attachment 98739 [details] Offending file
I can confirm this problem for evince ver. 2.26.2. This bug is now nearly 2 years old and still UNCONFIRMED. Please have a look at it.
No change in ver. 2.28.0. Ubuntu users created a bugreport, too: https://bugs.launchpad.net/evince/+bug/275786
Confirmed on 2.29.1. I also tried to see it under xdvi and I saw the 3rd roots which were lacking under evince. Marking this bug as 'NEW'.
*** Bug 603403 has been marked as a duplicate of this bug. ***
Created attachment 172150 [details] [review] proposed patch Basically the problem is that the glyphs are being drawn with their white background. The white background box of the root symbol is covering up the 3 (if it's a cubed root) because it is drawn after the 3. The proposed fix is to draw the glyphs such that their white background is drawn transparent.
A couple things I forgot to mention. The patch is against evince 2.30.3 as bundled with Ubuntu 10.04, since it is a very small patch, I hope this is okay. Also, I did a write-up of the fix on my blog, that explains the diagnosis and solution is a bit more depth. http://carlosrendon.wordpress.com/2010/10/11/evince-dvi-problems-or-gnome-bug-494736/
Review of attachment 172150 [details] [review]: Thank you very much for the patch. ::: backend/dvi/cairo-device.c @@ +259,3 @@ + (color=0x00??????). Fixes gnome bug 494736 where cubed + roots are not displayed + */ Why can we assume that a full white pixel is meant to be transparent? Are you sure this doesn't break any other documents?
*** Bug 547221 has been marked as a duplicate of this bug. ***
Created attachment 172234 [details] simple testcase of color dvi see color.tex for the latex document that generates this dvi
Created attachment 172235 [details] latex to generate testcase
(In reply to comment #8) > Review of attachment 172150 [details] [review]: > > Thank you very much for the patch. > > ::: backend/dvi/cairo-device.c > @@ +259,3 @@ > + (color=0x00??????). Fixes gnome bug 494736 where cubed > + roots are not displayed > + */ > > Why can we assume that a full white pixel is meant to be transparent? Are you > sure this doesn't break any other documents? You are right, we can't make that assumption. evince does not properly handle cases with non-white background colors. See the simple color test dvi that I posted and compare it to xdvi or emacs. The patch posted fixes the white boxes around the text in the colored boxes, but removes the white boxes where white text should be. I agree that the existing patch has the potential to cause problems, especially if evince's dvi color support improves. What we probably want is a check to see if the color being placed is the same as it's background's color and if so change the color to transparent. Does this sound correct to you? I tested the patch on Ubuntu 10.10 (ships with evince 2.32) and it does not work. evince 2.30.3 compiled on Ubuntu 10.10 with my patch also had the problem. I'm currently debugging the issue. In short, there is more work to be done. I will keep you posted of future progress.
Created attachment 172786 [details] [review] Proposed Patch Version 2
I have improved the previous patch. First and foremost it is now working on evince-2.32.0 with cairo-1.10.0 on Ubuntu 10.10. The problem was that the ARGB32 surfaces for the glyphs were modified completely outside of cairo, so it thought they were just blank images and did not paint them. The patch now contains calls to cairo_surface_flush and cairo_surface_mark_dirty, before and after changing the image surface of a glyph. To address the previous review comment, this new patch now only sets transparency when converting the bitmap of the font to an image. This process is done by sampling regions of the bitmap and counting the number of bits. The number of bits decides what color to use in the image. If the number of bits is zero I have manually set the color to fully transparent. Ideally as the number of bits decreases the transparency would increase, instead of becoming fully transparent at no bits. I plan on tackling this issue next, but as the patch is now, I believe that it is a solid improvement. As before, I did a brief write-up with a couple of pictures. http://carlosrendon.wordpress.com/2010/10/19/evince-dvi-problems-or-gnome-bug-494736-part-2/
Created attachment 173747 [details] [review] Proposed Patch Version 3 Unlike the previous patch, colors now fade to transparency gradually. Also the hack to set the background for glyphs to fully transparent has been obviated. Colors are now generated consistently with transparency in mind. I also found a few bugs in draw_shrink_rule of backend/dvi/mdvi-lib/dviread.c. Basically it was deciding how dark of a rule (box or line) to place based on the scaling of the rule. This does not make sense to me. Why would scaling a box or line change it's color? draw_shrink_rule has comments that say this is for anti-aliasing, but it only picks one solid color. In addition, draw_shrink_rule's call to get_color_tables had the fg and bg parameters in the wrong order. I have replaced this function with a much simpler version that always uses the foreground color. At this point I have no plans for further improvements of the patch. Please review. Thanks.
Review of attachment 173747 [details] [review]: Thanks for the patch, I've just pushed it to git master with the mark_dirty change (see below) ::: cairo-device.c @@ +259,3 @@ *p = color; + /* tell cairo we did something */ + cairo_surface_mark_dirty(surface); We don't need to mark the surface dirty for every modified pixel, but just once when all pixels have been modified. I've added a new method to DviDevice to notify when the image is done and call mark_dirty only once per surface.