We'll update to 2.0.5.2 ASAP. Your help is very much appreciated! Thanks!
Tag 2.0.5.2 release
I just made the release. You can find it in the Files section.
Bump project version to 2.0.5.2 and copyright year in the .rc file
Integer truncation bug in handling of EMR_POLYLINE
I applied your change (that possible part of it) in [r40] and corrected the typo in the EMR_POLYLINE handling in [r41]. I also checked other commands for similar typos, but it seems this was the only broken. To be released as 2.0.5.2.
Correct typo in EMR_POLYLINE handling (#52)
Staticalize some methods in share/litePDF.cpp|.h (#52 Derek Foster)
I just figuerd (the compiler told me) why the functions cannot be const. They call GetUnit(), which calls a library (dll) function, which can modify internal state of the class (like by loading the dll and filling the function pointers). I will keep the static part of your patch.
OK, thanks for the update. If I don't see an update by Monday (Feb 24), I'll recommend to my coworker that we should make the change locally.
Yes, doing local changes has its consequences. It the light of your "fix ASAP", I believe the easiest is just to fix locally for the time being, then you do not need to wait for slow people like me. As you said, ideally after at least a confirmation from the author about the proposed changes. For the time frame, I wanted to look on it earlier, but I did not manage it for the past two weekends, which is a shame. I'm sorry. I may have some free time at the end of this week. I'll update this bug once...
Hi, zyx. Thanks for the clarification. Part of the reason that I didn't just request that my coworker make the change to our own local copy was that I wanted to be sure that you confirmed that it was a real bug (and that the fix I proposed was the correct fix for it) and not a misunderstanding on my part. Also, in general, if we change our own local copy of an external library to incorporate changes of our own, there can be negative consequences, such as: If we later encounter any additional bugs,...
Hi, zyx. Thanks for the clarification. Part of the reason that I didn't just request that my coworker make the change to our own local copy was that I wanted to be sure that you confirmed that it was a real bug (and that the fix I proposed was the correct fix for it) and not a misunderstanding on my part. Also, in general, if we change our own local copy of an external library to incorporate changes of our own, there can be negative consequences, such as: If we later encounter any additional bugs,...
I'm sorry for the misunderstanding. Your description for the suggested changes were all fine. I thought, and expected, that when you build on your own you also have it fixed locally (on the other machine), without a need to wait for me when I get some free time to do the changes. As if you'd have the changes deployed, it made more sense to just use them too, to avoid any overlook on my side (aka to provide a patch). I do not know how it works in your company, maybe you need to wait until the upstream...
Hi, zyx. To answer your question: "simpler" depends somewhat on what someone is used to doing and is set up to do. I hoped my description of the necessary changes would be sufficient. I have not personally actually built litePDF and its dependencies from source: Another employee does that (this is a big company!) and her setup for doing so is highly individual and quite complicated and not easily transported to my machine. We are looking at ways to simplify that, but for the time being, I found the...
Hi, zyx. To answer your question: "simpler" depends somewhat on what someone is used to doing and is set up to do. I hoped my description of the necessary changes would be sufficient. I have not personally actually built litePDF and its dependencies from source: Another employee does that (this is a big company!) and her setup for doing so is highly individual and quite complicated and not easily transported to my machine. We are looking at ways to simplify that, but for the time being, I found the...
"The litePDF is built on Windows, but its build files are very special. I cannot share it." I meant the files in the SDK, because they bundle the dependencies into a single .dll file. The CMake files in here expect the dependencies to be prebuilt and available as runtime dependencies (and as other DLL files). Honestly, I doubt anybody else tries to build the library, people might just use the SDK, because it's the simplest thing, thus if there are any issues with the CMake files in here, then nobody...
Hi, zyx. Thanks for the quick response. With regard to building litePDF from source, perhaps I am operating on old information or am misinterpreting what you said, but in ticket #47, on 2022-09-07, you said "The litePDF is built on Windows, but its build files are very special. I cannot share it." My company has a policy in which we are not allowed to use DLLs which we did not build from source. (This is to avoid supply-chain attacks where an attacker might post innocent source code, then put a trojan...
Hi, zyx. Thanks for the quick response. With regard to building litePDF from source, perhaps I am operating on old information or am misinterpreting what you said, but in ticket #47, on 2022-09-07, you said "The litePDF is built on Windows, but its build files are very special. I cannot share it." My company has a policy in which we are not allowed to use DLLs which we did not build from source. (This is to avoid supply-chain attacks where an attacker might post innocent source code, then put a trojan...
Thanks for a bug report. You are right, it's a copy&paste error. because there is no included way to build the library from source That's not true at all. There is that CMake project file, with which you can build the code yourself. You need the dependencies, like with everything, of course. consider also making the four ...ToUnitEx functions be declared 'static', and the four '..ToUnit' functions be declared 'const'. I am currently having to code workarounds for the fact that these functions are...
Integer truncation bug in handling of EMR_POLYLINE
Thank you very much for your quick attention to this, and also for creating such a great library! I look forward to using it and hopefully making some contributions myself eventually.
Thanks for a bug report. The litePDF 1.x used to be closed source and had the limitations. Since the 2.x the library is fully Open Source. I missed the note in the download.html page, it should not be there (funny it's at the very top). I removed it and added a link to the project page there as well.
Please clarify licensing terms and remove ambiguities and contradictions.
Note: It looks as though I accidentally filed this against "milestone 1.0", but I seem to be unable to change it.
Please clarify licensing terms and remove ambiguities and contradictions.
Ehm, this has not much to do with this ticket, right? Just it'll be bad for people reading closed tickets to see two very different things in a single ticket. Nonetheless, the litePDF API has no function to edit exiting signatures. The only way to do it is to use PoDoFo functions directly. If I recall correctly, the signatures in PDF have multiple conditions to be met to have them recognized, thus even if you remove the corresponding Annotation (signatures are special annotations), you'd need to...
Hello I want to ask you, is there any way to remove a signature that has been signed in a pdf file through signature name or signatureIndex? And reset it is an empty signature
Using GetPoDoFoDocument in Delphi
Hi, I'm afraid PoDoFo is C++ only. You can access it from C++Builder. With respect of the samples and such, checkout the PoDoFo sources at https://sourceforge.net/projects/podofo/ or its pages https://podofo.sourceforge.net/ . Note the version of PoDoFo used by the litePDF SDK, it's not the one on the GitHub.
Using GetPoDoFoDocument in Delphi
It looks like an encoding problem to me.
Oh, I see, I thought they are out of the screen. Drawing directly to the HDC returned by the litePDF, not using the EMF, would work better (unless the world transformations are used).
It was what I feared 0º and 180º texts are not displayed.
Hi, I'm afraid it's a limitation of the litePDF. I thought I mentioned it in the "Known issues" section at https://litepdf.sourceforge.io/download.html , but I see it's not there. The EMF uses world transformation matrices, which the litePDF doesn't work well with. They confuse the litePDF as much as it provides incorrect data. I do not see the horizontal texts in your screenshot (0° and 180°), are they also horizontally flipped in the output, as the vertical texts?
Problem with EMF
I'm sorry for the delay! I've tested it and it works on my side. Thank you for helping with this :) Cheers!
you must have had to link to it using the .lib file I said the litePDF build is very special and I mean it. There are no .lib files, apart of the litePDF.lib, which is part of the SDK. Do follow their build instructions, it should work for you, as it worked for many people before you. Unless those people failed to report any issue in the steps. I also suggest to try with the static build first, to avoid problems with C++ linking through .dll files. I cannot help you more, I'm sorry. This is way out...
No, I'm not looking for LitePDF files, I want to know how you compiled the .lib file to use in LitePDF. If you built PoDoFo on Windows, then you must have had to link to it using the .lib file, where did you get that file? You also must have needed zlib1.dll, which does not get created thru CMake.
No, I'm not looking for LitePDF files, I want to know how you compiled the .lib file to use in LitePDF. If you built PoDoFo on Windows, then you must have had to link to it using the .lib file, where did you get that file? You also must have needed zlib1.dll, which does not get created thru Make.
The litePDF is built on Windows, but its build files are very special. I cannot share it. With respect of the PoDoFo build, did you consult their README.html? It contains sections describing how to build PoDoFo under Windows: https://sourceforge.net/p/podofo/code/HEAD/tree/podofo/trunk/README.html#l364 Unfortunately, the code view doesn't provide the file as true HTML; it might be easier to read when you download it and open in a browser.
I was able to successfully build Podofo but it did not come with a .lib file. Did you use Linux to code lite PDF? If not, I would love to learn how you were able to build that because my attempts have been unsuccessful. If you could pass along the file if you have it, that would be incredibly helpful as well.
No no, it is correct, the PoDoFo is part of the litePDF.dll, thus you'd need the litePDF.pdb to get the PoDoFo symbols. Still, I do not provide these, the less for the release build. I'm afraid you face the problem with the C++ on the .dll level. It is sensitive to many things, one of them being to use the same C++ standard version in your project as is used to build the .dll file. Whether it's it or not I cannot tell for sure. I do not know what you are trying to achieve with the litePDF, but its...
Sorry, was saying the .pdb for litePDF.dll, but I suspect you might be right and I will need to go 1 layer deeper in order for the PoDoFo objects. It looks like LitePDF does not have support for document level Javascript, I tried to access this with PoDoFo using doc-> GetNamesTree(true)->GetJavaScriptNode(true) which is a valid document and should always work according to the documentation but I get a access violation. The violation comes from litePDF.dll, but I'm not sure if it's through there or...
Many thanks. The DLL from sdk 2.0.5.1 still works.
I do not have those .pdb files. If you need the PoDoFo, then I suggest to build it on your own. It'll help to avoid one layer, which can cause its own trouble (using C++ from a .dll proved to be tricky here). The PoDoFo project documentation and their tools or examples are a good source of information about that project. See its pages ans sources here on the SourceForge.
Issue rendering EMF files with PlayEnhMetaFile
I just made a 2.0.5.1 release with these changes. I need to rethink the whole world transformation matrix situation, because what the Inkscape does (and EMF) is that it wants the drawing to be slightly smaller, which the litePDF currently ignores. The best would be to draw to the litePDF's HDC directly, not using the EMF as the intermediate format, whenever possible. In any case, the world transformation matrix situation requires significant amount of time, not only for the coding, but also for the...
Tag 2.0.5.1 release
Prepare 2.0.5.1 release
I'm not exactly sure where it was messing up, but apparently, I needed the pdfLite.cpp in both the solution item and as a source file, and there's two separate pdfLite cpp files which makes it confusing. Also, I actually did need to link the .lib file in order for it to compile. Anyway, I got it working and I'm trying to understand the Podofo object and how to interact with it as the documentation is quite limited I'm having trouble because I don't have the PDB file associated with the .dll. Can...
I'm not exactly sure where it was messing up, but apparently, I needed the pdfLite.cpp in both the solution item and as a source file, and there's two separate pdfLite cpp files which makes it confusing. Also, I actually did need to link the .lib file in order for it to compile. Anyway, I got it working and I'm trying to understand the Podofo object and how to interact with it, I'm having trouble because I don't have the PDB file associated with the .dll. Can you pls provide that?
I copied your example exactly and it isn't working, wouldn't be asking otherwise. Have you tried compiling this from scratch? That's hard to believe, because other people do use the examples and they work for them. Check the other (closed) tickets here. Adding the cpp file causes other compilation issues with the openssl library. The OpenSSL library? There's no use of the OpenSSL API in the .cpp of the litePDF public API... You surely do something wrong. To make it clear: To use the C++ API of the...
I copied your example exactly and it isn't working, wouldn't be asking otherwise. Have you tried compiling this from scratch? Adding the cpp file causes other compilation issues with the openssl library.
If I read the errors properly, then you use the C++ API, aka the TLitePDF. You need to include in your project both the litePDF.h and the litePDF.cpp. The code in the litePDF.cpp is not part of the litePDF.lib. If you gave a try to (or at least looked on) the example projects you'll see how it works.
Similarly, its requiring the library, otherwise the build fails. Help pls.
So I tried to add the other .lib file and it's giving me the errors you see in the attachment.
So I tried to add the other .lib file and it's giving me the errors you see in the attachment.
Thanks for a quick test. I'd like to wait for Don's response too, in case his environment/data is different. The test .emf from the description seems to work properly here as well (I can see the circle in the resulting PDF). I will make a new release (around) the next week, unless I'm proved of any bad side effects with the test dll.
Clip region not applied properly (#37)
Great! Its works.
True, I guess so too. Please see https://sourceforge.net/p/litepdf/tickets/37/#2431 for a test litePDF.dll
Could you give a try to this test build in your environment/with your data, please? I reverted the previous commit and made different approach. The EMF file sets an "almost identity" world transformation matrix, which confuses the code. I made the code less strict about the values, considering matrix within 1e-2 as identity. It's a known limitation of the litePDF, it doesn't work well with the world transformations.
Ok, thanks. 5 out of 71 virus scanners on Virustotal report a virus. Would say that's a false positive.
Issue rendering EMF files with PlayEnhMetaFile
I'm reopening this. The change for this broke a test case from the [#43].
Faulty PDF
The change for [#37] doesn't work well here. I'll reopen that ticket instead. Please, follow it for any further updates.
By the way, my antivirus claims your litePDF_test.exe in the .zip file contains a virus and prevents me to open the file.
I forgot to add, it's usually not needed to link to the .lib file, because the TLitePDF class opens the .dll on the fly. The .lib linking is needed when using the C interface or when you need low level access to the PoDoFo structures.
Invalid or corrupt file error
Hi, the OMF version is for Delphi/C++Builder, while it looks like you are using Visual Studio. Use the non-OMF version instead, obviously. It's written in the https://litepdf.sourceforge.io/download.html download page too.
Invalid or corrupt file error
Faulty PDF
Hmm, that's bad. I cannot get to this before weekend, unless anything more urgent will postpone it a bit further. I'll let you know when I have anything.
Hi, thanks for the new release. Unfortunately the clipping is now broken. Please compare test__with_2040.pdf and test__with_2050.pdf. The circle should be clipped into half. Which is not.
Hi, only a quick info, I just made a 2.0.5.0 release. Let me know if it won't work for you. Thanks and bye, zyx.
Tag 2.0.5.0 release
Prepare 2.0.5.0 release
I hope this problem can be solved soon I won't have much hope, this is a complex task. Maybe if some volunteer steps in, who knows.
Thank you very much I hope this problem can be solved soon On Wed, Aug 3, 2022, 18:04 zyx mc-zyx@users.sourceforge.net wrote: I forwarded this to the PoDoFo: https://github.com/podofo/podofo/issues/3 I believe it'll be better to be supported by the PoDoFo, thus any PoDoFo user will benefit from the change, not only the litePDF project. Please see the PoDoFo ticket for any further updates. [tickets:#41] https://sourceforge.net/p/litepdf/tickets/41/ vietnamese unicode space character error* Status:...
I forwarded this to the PoDoFo: https://github.com/podofo/podofo/issues/3 I believe it'll be better to be supported by the PoDoFo, thus any PoDoFo user will benefit from the change, not only the litePDF project. Please see the PoDoFo ticket for any further updates.
vietnamese unicode space character error
Down to the Unicode standard, your text uses "Combining Diacritical Marks". Looking on the output, there needs to be done a lot of typography to place the diacritical mark at the right place. This is kinda out of scope for the litePDF, I'm sorry. Patches are welcome, but I do not plan to make the code complex in this regard myself. For the record, there are three ranges for the combining marks: 0x0300 - 0x036f combining diacritical marks 0x20d0 - 0x20ff combining marks for symbols 0xfe20 - 0xfe2f...
I shortened the text and let it draw only the few first words. The page.zip contains these files: page.emf - to see what had been sent page.log - decoded .emf content as the litePDF receives it page-abcde.log - a log for a page, which draws only "ABC DE" text, aka all ASCII. . Looking into the page.log, the GDI decided to split the text on the Unicode characters, sometimes with accents and bottom dots and so on. I do not know these low level font things, it seems to me the letters are a composition...
(I'm sorry, the browser doesn't let me add more attachments to the comment.) It generates this PDF, which looks better than that yours, but not as the expected.
The changes.patch shows the changes I use. Note of the LitePDFDrawFlag_EmbedFontsSubset, I get similar output when not using it, but this makes sure the receiving part shows the same thing as you.
Hi Sorry for replying late I tested with lf.lfCharSet = CHINESEBIG5_CHARSET but result not expected. This file is example when i use lf.lfCharSet = CHINESEBIG5_CHARSET On Sat, Jul 9, 2022 at 6:14 PM zyx mc-zyx@users.sourceforge.net wrote: It helped to me to set also correct lfCharSet on the LOGFONT structure, thus the code (and GDI) knows what to use. I tried with lf.lfCharSet = CHINESEBIG5_CHARSET; and it produced a better output (I do not know whether it's the right character set for your text,...