Thank you for fixing this Issue!
wpCompressFastFlate + wpCompressFlate now are showing same results with the "A" version.
Beiträge von prismab
-
-
As suggested i have sent an sample to support@wptools.de.
-
Ok. That makes the difference:
If you use the wpdf500w.dll (unicode) the embedded bitmap is 50% larger than if you use wpdf500a.dll (use_ansi_dll).
Are embedded bitmaps in pdf files need more space when i use unicode enncoding ?
chatgpt :| says No:
- The Unicode encoding used for the text content in a PDF file does not directly affect the size of embedded bitmaps within the PDF. The size of embedded bitmaps depends on the resolution, color depth, compression, and the number of embedded images, not the encoding of the text.Unicode is a character encoding standard that deals with the representation of text characters and does not directly impact binary data, such as images. When you embed a bitmap (image) in a PDF, it is typically stored as binary data, and the encoding of the text in the PDF is separate from the binary image data.
Is that true?
-
Thank you for your response!
I suggest to send you an example which will show the different behaviour.
Where i can drop the code with picture etc.? -
We used Delphi 11 !
Both Versions where wPDF Standard Versions.
Is there a "Plus" version ? -
After updating our wpdf components from 3.62 to v5.1.2 (wpdf500w.dll) the size of our created pdf has grown by 50% (!).
The pdf document was created with a (large) bmp. The settings when creating TWPPDFPrinter are the same.
For us that is an important issue.Any Ideas?
... thanks in Advance!
Here a snippet from the pdf content where the image is embedded, the field "/Length" is showing the difference.
wpdf 3.62
<<
/Type/XObject
/Subtype/Image
/Name/wpt1
/Width 3721
/Height 5262
/BitsPerComponent 8
/ColorSpace/DeviceRGB
/Length 341634
/Filter [/FlateDecode] >>
stream
wpdf5.1.2
<<
/Type/XObject
/Subtype/Image
/Name/wpt1
/Width 3721
/Height 5262
/BitsPerComponent 8
/ColorSpace/DeviceRGB
/Length 571218
/Filter [/FlateDecode] >>
stream