Activity for zyx
-
zyx committed [r43] on Code
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.
-
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...
-
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...
-
"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...
-
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...
-
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.
-
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...
-
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.
-
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).
-
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?
-
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...
-
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.
-
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...
-
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 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...
-
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.
-
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)
-
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.
-
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.
-
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, 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.
-
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.
-
I'm waiting for [#41] resolution, after which I plan to make a new release.
-
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, I'm sorry). Could you give it a try, please?
-
Faulty PDF
-
I fixed this in [r34]. The problem was handling of the MetaRgn, which is handled as saving the graphics context and restore it on restore, but the MetaRgn count was "inherited" incorrectly between saved graphics states, causing too many calls to Restore() and in turn an invalid PDF content stream.
-
Correct MetaRgn drawing context restore (#43)
-
Compile error: missing semicolons before overload
-
Fixed in [r33]
-
litePDF.pas: Correct syntax around `overload` statement (#44)
-
Weak PDF signature
-
I added in [r32] API to set signature hash algorithm and made it default to SHA512. It also required to increase the default reserved bytes for the signature. It applies only to the internal signing API, not to the manual signing API.
-
Add API to set signature hash algorithm and default to SHA512 (#40)
-
Specify how to reserve more bytes for signature in the error message
-
I've been busy with some other things, thus I didn't have time to look on this yet. This is still in my todo, together with the other litePDF opened tickets. I might get to this in the following days/weeks, maybe by the end of this month, unless anything else steps in.
-
Please see https://sourceforge.net/p/litepdf/tickets/38/ for more information
-
Signature Error
-
Exactly my mistake! You have found it. Do you mean you made the "pop" call, somehow accessing PoDoFo through the litePDF directly or even using the RestoreDC() GDI function without a pair SaveDC()? The list of the EMF instructions shows exactl one SaveDC() call and exactly one RestoreDC() call, from which I guess the problem is on the litePDF side, not on the way you use it.
-
I see. That explains why my build succeeds. I'll add the semi-colons to the sources.
-
Thanks you for the test case. There seems to be a problem in the drawing stream, probably a pop of the graphics context, without corresponding (pair) push. I'll investigate this further. Just by an accident, a user opened a thread about similar problem, this time using PoDoFo directly, but there it looks like a problem with the font. At least on the first look. You can see the thread on their mailing list.
-
Thanks for a bug report. What is the Delphi version you use, please? My X11 doesn't claim any error in this code, otherwise it would be spot at the very beginning.
-
Interesting. I do not have that application. Would you mind to share the re-saved PDF file, please? It can be compared and hopefully found out what causes the problem. My understanding is that it's either in the drawing stream, or in the PDF data itself. What's the most weird, it begun to show only recently, I didn't see it with the old versions, which is the reason why I wanted to re-test with the old versions first.
-
Nice, thank your for a quick and thorough testing of this. I thought it's a regression after some update (possibly a PoDoFo update, which is used for the low-level manipulation), but if all the SDK versions generate for adobe reader broken PDF, then it is not a regression. By the way, trying to open your PDF in evince 41.2 doesn't claim any error. It may not mean much, it can be the evince is just more forgiving (or the Adobe Reader less permissive after some update).
-
Thanks for a bug report. Do you use any SDK (which one, if so) or you build the latest sources on your own, please? I noticed something similar with the latest sources once, thinking it was my fault (due to some tests) and didn't pay much attention to it. If I read it correctly there's no text output, only drawing primitives. Then I'd guess the problem is possibly in the header/info of the PDF file. I need to dive into it, but I cannot promise when it'll be. My free time is limited at the moment....
-
DLL creation
-
Hi, you need to build the dependencies first, then you can build the litePDF. The list of dependencies used to build the SDK is on the download page. Those dependencies have their own dependencies as well. You can use whichever versions work for you. How to use CMake (or other build systems used by the respective dependencies) is included in the build system manual. With respect of the size, I do not think there is any debug symbol, the builds are done in the Release configuration. The size is related...
-
Thanks for a quick update. It looks like the font has saved incorrect glyph widths, causing the overlap. I'll check it some time soon, but no promises when it'll be. I'm sorry.
-
Thanks for the update. If it's same broken on both versions, then it's something else than I thought. Could you repack the files with something more standard, like a zip, please? I've a hard time to unpack it (when I unpack it all but the "expected" PDF claim size of several tera-bytes, which is a clear nonsense). By the way, no need to mention my nick, I receive mail notifications without it too, the same as you received my comment.
-
Do you have a code to generate the page, please? A minimal test case is welcome. I also do not know what to look for in the PDF, thus if there's anything wrong, then I've absolutely no idea what that is. That means I'd need also a picture of the expected result, to be able to compare it with the current result. Also, which exact version of the litePDF do you use, please? Being it the latest 2.0.4., could you try with 2.0.3.0, please? There had been a change on the PoDoFo side, which could cause some...
-
podofosign: Default to SHA512 and add argument to change the digest
-
Patch by Wolfgang Stoeggl: Fix -Wmemset-elt-size warnings
-
Patch by Wolfgang Stoeggl: Add missing guards to header files
-
Patch by Wolfgang Stoeggl: Silence unknown pragma warnings under MINGW
-
Patch by Mark Rogers: Check that /DecodeParams values are in range (CVE-2018-20797)
-
Thanks for a bug report. I do not know which method to sign the document you use, but I do not see any force of a certain SHA algorithm in the litePDF itself, thus for example if you use https://litepdf.sourceforge.io/sign.cpp.html , then it can be the OpenSSL's default hash algorithm is SHA1. You can use any hash algorithm when using https://litepdf.sourceforge.io/signmanual.cpp.html , where you've everything under your control. I'll see whether there can be done anything with the OpenSSL signi...
-
Patch by F.E.: Ignore "/Prev 0" in trailer
-
Add FontTest::testBig2Little() unit test
-
Revert the previous commit (r2051) - it causes stack overflow
-
Patch by Michal Sudolsky: Fix undefined behavior in PdfFontTTFSubset.cpp:Big2Little
-
Patch by Andreas Brzesowsky: Add support for revision 6 encryption (PDF1.7 extension 8, PDF 2.0)
-
Patch by Mark Rogers: Add tests for stack overflow infinite recursion for CVE-2018-8002, CVE-2021-30470, CVE-2021-30471, CVE-2020-18971
1 >
