Mr. Nages please: HARU PDF Bugs/Extensions

User avatar
byte-one
Posts: 1048
Joined: Mon Oct 24, 2005 9:54 am
Location: Austria
Contact:

Re: Mr. Nages please: HARU PDF Bugs/Extensions

Post by byte-one »

Mr. Nages, now a use the METHOD PrintImage() as you recommending. If i use as uImage an existing bitmap-object, on tprinter is ok but in fwpdf i get this error:
Called from: => HB_HHASKEY( 0 )
Called from: .\source\classes\FWPDF.PRG => FWPDF:GETIMAGEFROMFILE( 732 )
Called from: .\source\classes\FWPDF.PRG => FWPDF:PRINTIMAGE( 796 )
Regards,
Günther
---------------------------------
office@byte-one.com
User avatar
nageswaragunupudi
Posts: 8017
Joined: Sun Nov 19, 2006 5:22 am
Location: India
Contact:

Re: Mr. Nages please: HARU PDF Bugs/Extensions

Post by nageswaragunupudi »

You may use any image file name, image resource or image from web, hBitmap, or gdi+ pImage.
But not any objects.
If you have a bitmap object, you can use oBmp:hBitmap.

If you are creating a bitmap object only for the purpose of printing, that is totally an unnecessary step. You can save code buy directly specifying the original source of the image.

Same with fwpdf and printer class.
Regards

G. N. Rao.
Hyderabad, India
User avatar
byte-one
Posts: 1048
Joined: Mon Oct 24, 2005 9:54 am
Location: Austria
Contact:

Re: Mr. Nages please: HARU PDF Bugs/Extensions

Post by byte-one »

Mr. Nages, i have a fix height of the picture to print. I must set the width of print respecting the ratio. So i calculate it with nPic_x := int( nPic_y * (oImage:nWidth() / oImage:nHeight()) ) from the predefined picture. The parameter lStretch := .T. without a nWidth gives wrong results! (different in tprinter and fwpdf)

An other interesting effect is the print from transparent PNGs: In tPrinter gives in the preview exact transparent pictures but in the real print the transparence is lost. Printing the PDF-file from fwpdf is correct and transparent!
Regards,
Günther
---------------------------------
office@byte-one.com
User avatar
nageswaragunupudi
Posts: 8017
Joined: Sun Nov 19, 2006 5:22 am
Location: India
Contact:

Re: Mr. Nages please: HARU PDF Bugs/Extensions

Post by nageswaragunupudi »

If the rectangle you specify (nrow, ncol, nwidth, nheight) is smaller than the size of the image, all our latest functions shrink the image to fit the rectangle, without losing aspect ratio.
You better let the FWH functions do it. They give good quality and we keep improving the quality.

You can reduce a lot of coding.

Also if you give the file name directly, lot of conversions will be avoided and you get better quality output.

About printing alpha images: Your printer needs to support alpha printing. Not all printers support.
Try the latest jet printers and you get this well. The limitation is the printer not fwh
Regards

G. N. Rao.
Hyderabad, India
User avatar
byte-one
Posts: 1048
Joined: Mon Oct 24, 2005 9:54 am
Location: Austria
Contact:

Re: Mr. Nages please: HARU PDF Bugs/Extensions

Post by byte-one »

With method PrintImage() pictures with fwpdf not showing or the ratio not correct! Please try with nHeight and nWidth with 20mm.
http://byte-one.com/1.png
http://byte-one.com/2.png
http://byte-one.com/3.png
If i before redefine with REDEFINE BITMAP .... and later using oBitmap:hBitmap in PrintImage(..) is all ok!
Regards,
Günther
---------------------------------
office@byte-one.com
User avatar
nageswaragunupudi
Posts: 8017
Joined: Sun Nov 19, 2006 5:22 am
Location: India
Contact:

Re: Mr. Nages please: HARU PDF Bugs/Extensions

Post by nageswaragunupudi »

FWH TPrinter class is able to read and render all the above images. All FWH image functions and classes can handle these images.

But FWHPDF can read and render 2.png only. Reads 1.png as blank image and crashes while reading 3.png.
The problem is not with FWH.

FWPDF is basically a wrapper for harupdf library functions. In addition, FWH added some additional imaging functionality that is not possible with the in-built functions of libharu.

Libharu has inbuilt functions for png and jpg files/image buffers. In addition, it has one function to read images from memory formtted in its proprietory format.

Code: Select all

HPDF_LoadPngImageFromFile
HPDF_LoadJpegImageFromFile

HPDF_LoadPngImageFromMem
HPDF_LoadJpegImageFromMem

HPDF_LoadRawImageFromMem
 
Libharu, on its own, can not read any other file types. In all such cases, FWH reads the images with its own functions and then generates suitable buffer in the memory and uses HPDF_LoadPngImageFromMem() for alpha images and HPDF_LoadRawImageFromMem() for non-alpha images. Except FWPdf, no other wrapper class like TPdf can handle images other than png and jpeg.

This is how FWH extends the capabilities of libharu and enables FWPDF class to handle any image type.

In the case of above images, both HPDF_LoadPngImageFromFile and HPDF_LoadPngImageFromMem fail to read 1.png and 3.png. We may call it limitation of libharu or incompatibility of our images with the libharu's built-in functions.

I have used PixelFormer.exe to import both 1.png and 3.png and re-export them in png format to 11.png and 33.png. This conversion also reduced the sizes of the files drastically.

Code: Select all

1.png (1,006,696 bytes) --> 11.png (165,938 bytes)
3.png (   86,227 bytes) --> 33.png ( 83,362 bytes)
 
Now, libharu is able to read these new images and this is the program using the new images;

Code: Select all

#include "fivewin.ch"

REQUEST FWHARU

function Main()

   local oPrn, oFont, oPen, oBrush
   local cPdfFile
   local uImage
   local nRow, nCol, nWidth, nHeight
   local s1, s2

   TPrinter():lUseHaruPDF  := .t.

   if MsgYesNo( "HaruPdf?" )
      cPdfFile := "test.pdf"
   endif

   PRINT oPrn PREVIEW FILE cPdfFile
   DEFINE FONT oFont NAME "ARIAL" SIZE 0,-20 OF oPrn
   DEFINE PEN oPen WIDTH 1 OF oPrn
   DEFINE BRUSH oBrush FILE "c:\fwh\bitmaps\backgrnd\browback.bmp"

   PAGE

   nWidth := nHeight := 2
   nRow  := 1
   nCol  := 0.75

   uImage   := "https://imagizer.imageshack.com/img923/1482/4FId0E.png"
   oPrn:Box( nRow, nCol, nRow + nHeight, nCol + nWidth, oPen, nil, nil, "INCHES" )
   @ nRow, nCol PRINT TO oPrn IMAGE uImage SIZE nWidth, nHeight INCHES

   nCol     += 0.5 + nWidth
   uImage   := "http://byte-one.com/2.png"
   oPrn:Box( nRow, nCol, nRow + nHeight, nCol + nWidth, oPen, nil, nil, "INCHES" )
   @ nRow, nCol PRINT TO oPrn IMAGE uImage SIZE nWidth, nHeight INCHES

   nCol     += 0.5 + nWidth
   uImage   := "https://imagizer.imageshack.com/img924/4041/WWsR34.png"
   oPrn:Box( nRow, nCol, nRow + nHeight, nCol + nWidth, oPen, nil, nil, "INCHES" )
   @ nRow, nCol PRINT TO oPrn IMAGE uImage SIZE nWidth, nHeight INCHES

   nWidth   := 6
   nHeight  := 3
   nRow     := 3.5
   nCol     := 1

   uImage   := "https://imagizer.imageshack.com/img923/1482/4FId0E.png"
   oPrn:Box( nRow, nCol, nRow + nHeight, nCol + nWidth, oPen, oBrush, nil, "INCHES" )
   @ nRow, nCol PRINT TO oPrn IMAGE uImage SIZE nWidth, nHeight INCHES

   nWidth   := 6
   nHeight  := 1
   nRow     := 7.0
   nCol     := 1

   uImage   := "https://imagizer.imageshack.com/img924/4041/WWsR34.png"
   oPrn:Box( nRow, nCol, nRow + nHeight, nCol + nWidth, oPen, nil, nil, "INCHES" )
   @ nRow, nCol PRINT TO oPrn IMAGE uImage SIZE nWidth, nHeight INCHES

   ENDPAGE
   ENDPRINT

   RELEASE FONT oFont
   RELEASE PEN  oPen
   RELEASE BRUSH oBrush

return nil
 
Image

We are further examing the issue in these lines.
libharu depends on zlib and pnglib. We are using the png.lib in our (x)Harbour libraries. We need to see if there is a need to replace or update this lib.
Regards

G. N. Rao.
Hyderabad, India
User avatar
nageswaragunupudi
Posts: 8017
Joined: Sun Nov 19, 2006 5:22 am
Location: India
Contact:

Re: Mr. Nages please: HARU PDF Bugs/Extensions

Post by nageswaragunupudi »

It is noticed that libharu.lib along with the present png.lig of (x)Harbour is unable to read some png files/buffers.

Temporarily, we modified the fwpdf.prg. Now png images are first read by FWH own functions, bypassing the libharu native functions and then create pdf images from the gdi+ image read by FWH.

With this change, fwpdf is able to read all the 3 images provided above.
Regards

G. N. Rao.
Hyderabad, India
Post Reply