Q:
We're in the process of integrating the PDFNet SDK with our
application on OS X. Already completed successfully on Windows.
I'm using PDFView::GetBuffer() and wrapping the returned buffer with a
QImage (Trolltech Qt):
const char* buf = m_pdfView.GetBuffer();
QImage img = QImage( (uchar*) buf, m_bufferWidth, m_bufferHeight, 32,
0, 0, QImage::LittleEndian );
We can then proceed to render the QImage in our application window.
This works fine on Windows and on the Mac with the PDFNet OS X Intel
SDK. However when we do the same thing with the PDFNet PowerPC SDK,
the PDF page and its background have a blue cast.
Any thoughts as to what the problem might be?
Is the pixel format we get back from GetBuffer() the same on Intel and
PPC?
-----
A:
The problem is that PowerPC Macs use big endian architecture.
On an Intel computer, the little end is stored first. This means a Hex
word like 0x1234 is stored in memory as (0x34 0x12). The little end,
or lower end, is stored first. The same is true for a four-byte value;
for example, 0x12345678 would be stored as (0x78 0x56 0x34 0x12). "Big
End In" does this in the reverse fashion, so 0x1234 would be stored as
(0x12 0x34) in memory.
To go around this problem you could swap bytes in RGBA buffer (or
perhaps use QImage::BigEndian flag?).
Is the pixel format we get back from GetBuffer() the same on Intel and PPC?
The pixel format (R,G,B,A) returned by GetBuffer() should be the same
on both Intel and PPC machines.