Beiträge von simtec

Hi,

is there a possibility to create hyperlinks which will launch an application (exe) with additional parameters?

Function SetLinkArea() does only allow the keyword "Launch://".

Using it with the exe name (e.g., "Launch://C:\\WINDOWS\\notepad.exe") works so far.

But adding paramters to the exe name (e.g., "Launch://C:\\WINDOWS\\notepad.exe C:\\Temp\\MyFile.txt") ends up with an error message that "C:\\WINDOWS\\notepad.exe C:\\Temp\\MyFile.txt" can't be found.

I found out that there is an additional setting /P which can be added to the launch action embedded into the pdf. See https://stackoverflow.com/a/19455918

Can I do this with wPDF in any way?

Please note:

• notepad.exe is just used to illustrate the issue here.
• Yes, I know that Acrobat Reader has been changed not to open hyperlinks to exe files by default. Others do and even Acrobat does provide registry settings to allow it (and we require it just for internal puposes where the risk is known).

Kind regards,

Michael

Thank you very much for your suggestions.

But they are more or less just workarounds for these issues. Why should I have to deal with things like correct position and length of the underline and the correct line width if the used font already does it sufficiently? Also using a separate rectangle to be able to use a different background color is not really a simple solution.

Printing the first blank on the wrong position (which does not only happen with underlined fonts, it also can be observed when using a different background color) did not appear with wPDF V4.38. The next version I used is V4.71.1 and there the bug can be observed.

It seems that wPDF handles leading spaces in a not correctly special way. Using non-breakable spaces instead of "normal" spaces works reasonably, but it is also just a workaround.

Maybe your advice to use baseline alignment does help, but I didn't find any property or function to set this. How do I use "baseline alignment"?

If I use the standard TexOut() function on e.g., a Metafile canvas which I use to display a preview of the pdf, the background color is set as expected over the whole string regardless if there are leading spaces or not. The background color bug does only appear in the pdf created by wPDF and it does not make any sense to me that the behaviour of wPDF's TextOut() is different.

Best regards,

Michael

Sorry for delayed answering, I was away some days...

I'm not sure what you mean with "result value".

As far as I could see in the available Delphi files (WPPDFWP.pas) are both BeginDoc() and EndDoc() declared as procedures. There is no result value!?

We use wPDF with C++ Builder 10.3.1 Rio. The package was built from DX13 (but also the previous versions were affected).

BeginDoc() works as expected: It throws the exception EFCreateError. I can catch it and handle its occurence.

EndDoc() does NOT throw that exception. It is catched inside EndDoc() and not forwarded. I can't catch it.

Hi,

if a document is created in memory (InMemoryMode = true) the pdf file is created if function EndDoc() is called.

If the file can't be created the exception EFCreateError is thrown. But this exception is not forwarded and can't be catched by the user's code:

try
{   wPDF->EndDoc() ;
}catch (Exception &ex)
{
   // Bug: Exception handler is not called if exception EFCreateError occurs in EndDoc()!!!}

On the other hand:

If the document is not created in memory (InMemoryMode = false) the pdf file is created if function BeginDoc() is called.

If the file can't be created the exception EFCreateError is thrown and forwarded as expected. It then can be catched by users code:

try
{
   wPDF->BeginDoc() ;
}
catch (Exception &ex)
{
   // Ok: Exception handler is called if exception EFCreateError occurs in BeginDoc()!!!
}

This issue has been evaluated with wPDF V4.75.1 used by C++ Builder 10.3.1 Rio.

In my opinion it is a bug. Maybe it will be fixed in the next release of wPDF!?

Best regards

Michael

Hi,

we discovered some issues with function TextOut() when strings with leading spaces shall be printed:

1. If the string to be printed with Canvas->TextOut() contains leading blanks, only the first blank is displayed with the background color set in Canvas->Brush->Color and the remaining string is displayed with the standard background color (white).
   Conclusion: It is not possible to print a string with leading spaces in a different color than white.
2. If the Canvas->Font->Style (FontStyle) contains fsUnderline then the first (underlined) blank of the leading blanks is printed at a wrong position (much too below with a wrong Y position). The following blanks then are displayed at the correct position.
   To workaround this issue we decided to replace the leading blanks by non-breakable blanks (U+00A0) which are displayed at the correct position. But this resolution has a drawback concerning the alignment of the printed lines if the widths of the "usual" blank (U+0020) and the non-breakable blank (U+00A0) are different.

These issues were evaluated with wPDF V4.75.1 used with C++ Builder 10.3.1.

Maybe they could be fixed in the next relase of wPDF!?

Best regards,

Michael

Hi Julian,

thanks for the hint. We have been using refPrinter for years, so I could rule that one out. wpNoTextScaling didn't do the trick either. But after you pointed me at the Modes property, I found the one that now made things work again, it's wpExactTextPositioning (someone here has been doing severe positioning calculus, the new wPDF seems to "optimize" that out of existence, maybe fixing a bug that didn't properly evaluate "Modes"). Thanks for putting me in the right direction!

Best Regards,
Ute

We are using wPDF with C++ Builder XE8. End of July, we switched to the wPDF4 DLL build dated May 27th, 2015.
For the last few years, we had more or less the same printing algorithm that created our documents using monospace font Futura Lt BT. All letters aligned well.

When we use the new DLL with current or older, previously functional versions of our software, it sometimes happens that single lines of text are rendered slightly too narrow. If we simply use the old code and old DLL, all is well.
The difference is minimal, yet noticeable. Example: in a document that is zoomed to 85cm displayed width, the offset between previously aligned digits near the end of the line is about 2mm. Since we need our text well-aligned (and this is why we picked a monospace font), the result is not acceptable.

Is this a bug or does the new build require different handling? What should we be doing to get good results in monospace print?

We are currently updating our projects from Borland XE5 to XE8. Unfortunately, the latest wPDF4 installer is two months old and therefore only provides support up to XE7.

Is there a way to make the current version of wPDF4 work with XE8?
If not, is there an estimate when XE8 support will be available?

I am using Borland C++ XE5 to set up a printing tool.
The goal is to allow printing, copying and comments, but not content editing.

Because I found no Encryption flag for text enhancements (highlighting/commenting), I started testing combinations of flags to figure out if there is one that does the trick.
During my experiments I found that using wpEnableCopying or wpEnableFormFieldFillIn enables printing for my setup, but not copying or editing.
To allow copying, but neither printing nor editing, I need to specify wpEnablePrinting and wpEnableAccessibilityOp.
If I specify wpEnablePrinting only, none of the above is possible.
Is there something wrong with my library or is there an incompatibility between wPDF4 and Adobe Acrobat XI?

Also, does anybody know a way to specify the settings mentioned above? I have tested around 120 of the 512 possible flag combinations and am getting a little tired of the brute force approach (change flags, rebuild, run, verify, note, repeat).