Text.Pdf.mod draws images wrong into PDF Documents

[MidimasterSoft]

I do my first steps with text.pdf.mod and was able to add pixmaps into the PDF document. As long as i use a PNG, where X-dimension (WIDTH) is a multiple of 4 (fe. 480x301pix) everything works fine.

but when I use the odd dimension (like (481x301pix) the image in the document gets a horizontal shift like a parallelogram

This is my code:

SuperStrict
Import Text.PDF
Local pdf:TPDFDoc = New TPDFDoc
Local page:TPDFPage = pdf.AddPage()

page.SetWidth(560)   
page.SetHeight(900) 

Local PixMap:TPixmap = LoadPixmap("Zeile1550.png")
Local Image:TPDFImage = pdf.LoadImage(PixMap)
page.SetRGBFill(1.0, 0, 0)
page.DrawImage (Image, 10,770, 550,127)
pdf.Save("NotesExample.pdf")
pdf.Free() 

(I use BlitzMax NG latest release from here)

and this is a example image, which produces the problem

When I expand it to a 1560x300pix PNG the module works as expected

[GWRon]

I am not sure how stuff is handled - but maybe there is some striding happening.

LibHaru expects some packed image data without padding (so pixel data after pixeldata no "fill up" for each line). A TPixmap does "pitching" -- so seems to "fill up" -- this is done I guess for renderer-performance optimizations (renderers might prefer the 4byte aligned stuff) .

btw there is HPDF_LoadPngImageFromFile ... which might be something we could check (if it works correctly then ... because it cares of these padding issues automatically)

Ok, the following code is untested but should care about the pitching in TPixmaps:

Method LoadImage:TPDFImage(pix:TPixmap)
    If pix.format <> PF_RGB888
        pix = pix.Convert(PF_RGB888)
    EndIf

    ' LibHaru expect unpadded pixmap data, TPixmap uses padding
    ' (fills up lines to "4 byte" alignment)
    ' So we need to strip the padding again
    Local bpp:Int = 3 ' RGB888 uses 3 byte per pixel
    Local srcPitch:Int = pix.pitch
    Local dstPitch:Int = pix.width * bpp 'could of course be * 3 here...
    Local buf:Byte Ptr = MemAlloc(dstPitch * pix.height)

    For Local y:Int = 0 Until pix.height
        MemCopy(buf + y * dstPitch, pix.pixels + y * srcPitch, dstPitch)
    Next

    Local img:TPDFImage = TPDFImage._create(HPDF_LoadRawImageFromMem( ..
        docPtr, buf, UInt(pix.width), UInt(pix.height), EPDFColorSpace.DEVICE_RGB, 8))

    MemFree(buf)

    Return img
End Method

@woollybah might have some more performant approach at hand

[GWRon]

@woollybah if you implement such a thing we should consider if we improved "TPixmap" to have helper functions ...

Function PixmapToPacked:Byte Ptr(pix:TPixmap, outSize:Size_T, mustFree:Int Var)
    Local bpp:Int = BytesPerPixel[pix.format]
    Local rowBytes:Size_T = pix.width * bpp
    outSize = rowBytes * pix.height

    ' already packed?
    If pix.pitch = rowBytes
        mustFree = False
        Return pix.pixels
    EndIf

    ' copy into new buffer
    Local buf:Byte Ptr = MemAlloc(outSize)
    For Local y:Int = 0 Until pix.height
        MemCopy(buf + y * rowBytes, pix.pixels + y * pix.pitch, rowBytes)
    Next

    mustFree = True
    Return buf
End Function

The inconvenience here is: you need to handle "mustFree" (MemFree(buf) when you are done). So it might be better to either:

• use a TBank (so TPixmap.ToUnpaddedBank:TBank) or maybe some helper type (TPixmapUnpaddedData).

[MidimasterSoft]

But a simple workaround solves the problems too: Ensure, that the Pixmap Width is a multiple of 4

[GWRon]

Wouldn't it be better to check if such an "unpadding" works for you than having to do workarounds which of course lead to slightly different output sizes of the content (the added width is whitespace which is scaled up then too).