Called from: => HB_HHASKEY( 0 )
Called from: .\source\classes\FWPDF.PRG => FWPDF:GETIMAGEFROMFILE( 732 )
Called from: .\source\classes\FWPDF.PRG => FWPDF:PRINTIMAGE( 796 )
Mr. Nages please: HARU PDF Bugs/Extensions
Re: Mr. Nages please: HARU PDF Bugs/Extensions
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:
- nageswaragunupudi
- Posts: 8017
- Joined: Sun Nov 19, 2006 5:22 am
- Location: India
- Contact:
Re: Mr. Nages please: HARU PDF Bugs/Extensions
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.
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
G. N. Rao.
Hyderabad, India
Re: Mr. Nages please: HARU PDF Bugs/Extensions
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!
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!
- nageswaragunupudi
- Posts: 8017
- Joined: Sun Nov 19, 2006 5:22 am
- Location: India
- Contact:
Re: Mr. Nages please: HARU PDF Bugs/Extensions
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
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
G. N. Rao.
Hyderabad, India
Re: Mr. Nages please: HARU PDF Bugs/Extensions
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!
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!
- nageswaragunupudi
- Posts: 8017
- Joined: Sun Nov 19, 2006 5:22 am
- Location: India
- Contact:
Re: Mr. Nages please: HARU PDF Bugs/Extensions
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.
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.
Now, libharu is able to read these new images and this is the program using the new images;
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.
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
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)
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
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
G. N. Rao.
Hyderabad, India
- nageswaragunupudi
- Posts: 8017
- Joined: Sun Nov 19, 2006 5:22 am
- Location: India
- Contact:
Re: Mr. Nages please: HARU PDF Bugs/Extensions
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.
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
G. N. Rao.
Hyderabad, India