[GRASS-dev] Re: [GRASS GIS] #937: cairo driver: d.legend colors all broken

[GRASS GIS]

#937: cairo driver: d.legend colors all broken
----------------------+-----------------------------------------------------
  Reporter:  hamish   |       Owner:  grass-dev at lists.osgeo.org
      Type:  defect   |      Status:  closed                   
  Priority:  major    |   Milestone:  7.0.0                    
 Component:  Display  |     Version:  svn-trunk                
Resolution:  fixed    |    Keywords:  cairo, d.legend          
  Platform:  Linux    |         Cpu:  x86-64                   
----------------------+-----------------------------------------------------
Changes (by hamish):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Replying to [comment:4 glynn]:
 > But looking at the image, I'm guessing that it's an alignment
 > problem. The header is 54 bytes, which isn't a multiple of 4.
 > The documentation for cairo_image_surface_create_for_data() says:
 >
 > > This pointer must be suitably aligned for any kind of variable,
 > > (for example, a pointer returned by malloc).
 >
 > It wouldn't surprise me if an unaligned frame buffer behaves
 > incorrectly on x86-64.
 >
 > Try r41029; this pads the header to 64 bytes in everything which
 > reads/writes these files (PNG driver, cairo driver, ximgview,
 > wximgview, wxpyimgview). The offset to the data is stored in the
 > header (to allow for variable-length fields and the addition of
 > new fields), so the files should still be legal (not that most
 > software can handle them anyhow).

 bingo. that fixed it.

 `qiv` still opens the .bmp as a scrambled 640x64 mess, but I guess that's
 due to it not liking the 32bitness of it.

 just out of curiosity, how do the .bmp, .ppm, and SGi's .rgb differ, in
 that IIUC they are all just raw binary dumps of width height r1g1b1 r2g2b2
 r3g3b3 ...
 ?


 Hamish

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/937#comment:5>
GRASS GIS <http://grass.osgeo.org>