Beiträge von ehimmer

    It was suggested a while back to use the [wpAllSymbolFontsAsGlyph] option to improve something or another (can't recall). Up until recently it had seemed ok but now they seem to show up in the PDF too low on the line in relation to the other text. Maybe some wPDF or Windows update started this? Maybe it's always been like this and I just now noticed it.

    Anyway, I've tried several Symbol chars such as 0xB7 (medium bullet) and 0xA8 (diamond) which looks positioned correctly in Print Preview but not in the PDF when using the wpAllSymbolFontsAsGlyph option. Some of the Wingdings chars like a small bullet 0x178 and large bullet 0x6C look OK in both Print Preview and PDF. Are Wingdings considered Symbols in this case? Maybe another option is required?

    wPDF400W.dll 4.82.1.0

    When exporting to PDF, you added support for PNG transparency in wPDF4 and works great; however, when printing to a printer PNG transparency is lost. The obvious get around is to export to PDF and then print the PDF, but is it possible to support it when printing to a printer to save a step? None of our customers have complained about it, but it might come up at some point.

    I was able to finally trace it down. It works if I copy the png graphic to a TMemoryStream and then call WPWriteComment something like this in the PaintWatermark event:

    Code
    WPWriteComment(pCanvas.Handle, WPDFCOMM_DRAWPNGDATA, pPageRect, vStream.Memory, vStream.Size)

    I can also use this approach to paint the watermark as an overlay instead of as a true watermark. This allows me to be able to create fancy cover pages that masks out everything except what is in the transparent area, such as a for framing a picture of something in any frame shape. Looks a bit weird (low resolution for the parts in the transparent area) when in Print Preview, but comes out fine in the PDF. Print Preview is using StretchDraw, so maybe something needs tweaking there on my part.

    For a test, I added the same PNG image to the body as well as a watermark. In print preview, both were transparent. However, in the PDF, only the body was transparent, the watermark was not.

    I examined the PDF and saw that the only difference in how the PDF "described" the image stream was that the transparent one had "/SMask 6 0 R" as part of the properties but the watermark did not. I edited the PDF and added "/SMask 6 0 R" to the watermark image properties, and then it was transparent.

    I use StretchDraw in the PaintWatermark even when outputting the watermark, but I haven't been able to trace down to how you output a PNG image that is in the body when exporting to PDF so that I could mimic how you do it to support transparency in the body (my customers don't necessarily know how to convert their logo to a non-transparent bitmap with white replacing transparency, so I would like to support it for watermarks if possible). I see you have a printmode option of wppInPaintForwPDF that I could conditionally chose one method over the other.

    Any help you can provide would be great.

    If I specify to use a PNG file that has transparency for a watermark, it looks fine in WPTools Print Preview but the transparency parts of the PNG watermark come out as black when exported to a PDF. Is this expected or am I missing something. I even tried enabling the Export mode to wpAllowTransparentBit. Using WPDF4 and is defined in WPINC.INC.

    With 64bit builds, it appears to be related to WPPreview1's ViewOptionsEx of wpDisable2PassPaint. If I set this to True, spaces take on the text background color at all times, but can overlap any following area by about a half a char width, but not always. Also, some text gets "washed" out a bit, so not a great solution to set that option to true. I don't quite get why spaces always has the background color with the 32bit build but not with the 64bit build. Any ideas?

    If I select several words and change the text background color to yellow for example, the spaces will sometimes not be yellow or flicker between yellow and white as you drag a mouse to select the text again (not easily reproduceable). Also, if you do a print preview and use the scrollbars to find the page that the text with a yellow background is, the spaces will be white until you use a mouse scroll wheel to scroll the page, then the spaces become yellow as they should. The print preview/scrollbar method is easily reproduceable.

    Sample, edit on left, print preview on right

    I tested AWoell's theory from the 2006 thread mentioned above about the eating of WM_IME_CHAR as maybe being wrong and tried re-enabling IMEIMPUT and adding inherited WndProc(Message); as below in TWPCustomRtfEdit.WndProc

    This seems to allow for handwriting recognition to work as well, but not sure what it might break in regards to IME input.

    Code
       if Message.Msg = WM_IME_CHAR then
       begin
            inherited WndProc(Message);  // Test: added for handwriting recognition
             exit;
       end else

    This change also allows for accented chars and emojis to be entered using the US keyboard method described here:

    Special chars

    Handwriting recognition using the Windows TabTip keyboard on tablets does not function when IMEINPUT conditional compilation switch is in effect. (as first mentioned for WPTools 5 back in 2006, 2006 thread). This is still the case with WPTools9. However, FYI, the same "fix" by turning off IMEINPUT causes a compilation error because the two routines in WPCTRMemo: TWPCustomRtfEdit.WMIMEComposition and TWPCustomRtfEdit.WMIMEEndComposition are not both conditionally compiled out (they are in the interface section but not in the implementation section)... easily remedied manually of course.

    It would be helpful if handwriting recognition would work with IMEINPUT enabled. But if not possible, maybe make IMEINPUT a runtime option rather than a compile time option?

    Does disabling IMEINPUT cause any issues other than not being able to use IME INPUT? IME input definition I don't use or need the emoji insertion capability which seems to be part of it.

    In case others might want a curly line that looks like the one being used in Thunderbird email clients, you can make the following changes in WPRTEPaint:

    Code
        //curly_trad: array[0..11] of Integer = (0, -1, -1,  0,  0, -1, -1,  0,  0, -1, -1,  0);
        curly_trad:   array[0..11] of Integer = (3,  1,  0,  0,  1,  3,  3,  1,  0,  0,  1,  3);
    ...
          DestCanvas.Pen.Width := px2; // Changed Width from 0 to px2
    ...
          if (wpTraditionalMisspellMarkers in ViewOptions) then // Added conditional since start positions differ
            DestCanvas.MoveTo(LastLineSpellX, LastLineY + px2 + curly_trad[loop] * px1)
          else
            DestCanvas.MoveTo(LastLineSpellX, LastLineY + px2 + curly[loop] * px1);

    Currently the non-traditional curly line under misspelled words does not stand out very well in some circumstances (customer feedback). It appears to be a 1px line. Can an option be added to increase it to 2px. I changed the source in WPRTEPaint's DrawCurly procedure from: DestCanvas.Pen.Width := 0; to DestCanvas.Pen.Width := px2; which really makes it stand out nicely for us.

    Please ignore the 8bit version. I only mentioned that to indicate that it is fine and transparent even in the PDF for just that format when it is an embedded image.

    The 32bit versions should be the same. In testing, I simply write the stream to a file before writing the same stream to a WPRichText object for embedding. Both the embedded and linked image of the same stream show up as transparent in the editor and in the print preview, but only the linked image version is transparent in the PDF, the embedded version is not.

    OK, but they come out transparent if added as linked images but not when added as embedded images. I have no problem making them 8bit since the signatures are a single color anyway. Just strange that there seems to be a difference between being embedded vs being linked.

    To make them linked in a test, I simply wrote the stream to a file and inserted the file as a linked image whereas for embedded I take the same stream and embed the image:

    Code
          var vWPObject := WPCreateObjectForExtension(WPRichText1, 'png');
          if vWPObject <> nil then
          begin
            try
              vWPObject.FileExtension := 'png';
              vWPObject.LoadFromStream(vImageStream);
              PasteSignature(WPRichText1, vWPObject);
            except
              FreeAndNil(vWPObject);
            end;

    And PasteSignature basically just does this (pWPObject is vWPObject passed in):

    vTextObj := pWPRichText.TextObjects.Insert(pWPObject, pWPObject.ContentsWidth, pWPObject.ContentsHeight);

    Gets weirder. If I save either the 8bit or 32 bit versions of the PNG to a file and insert it into the WPRichText as a linked image, it works fine in the PDF (both are transparent). However, for signatures I insert them into the WPRichText as embedded images.

    So I guess that would be the difference, and would be why the sample PNG I had was working because it was a linked image and the signature testing was an embedded image.

    Something you may want to check out. Why an embedded PNG image needs to be 8bit to be transparent in a PDF but a 32bit PNG is not transparent in the PDF. Both are transparent in the editor and in Print Preview.