Re: [Podofo-users] std::auto_ptr --> std::unique_ptr
> Le 6 déc. 2018 à 08:25, zyx a écrit :
>
> I'd remove the std::auto_ptr usage from the public
> API completely, and use, if needed, either of them based on the
> compiler being used (and what it offers) only in internal code. That
> would support both old and new C++ standards.
It wouldn't work. There is no point in having an option to compile internal
code with (auto|unique)_ptr when interfaces would use unique_ptr. Because
unique_ptr support would then be required for internal code anyway, so why
would it need to insist on using auto_ptr in some places? :)
The readme.html is probably wildly outdated:
> Installation with CMake
>
> PoDoFo has support for builds using CMake on all supported platforms. The
> CMake build has been tested on:
>
> • Visual C++ 9 Express Edition [Win32] ("Visual Studio 9 2008" target)
> • Visual C++ 8 Express Edition [Win32] ("Visual Studio 8 2005" target)
> (needs additional setup)
> • Visual C++ 8 Express +NMake [Win32] ("NMake Makefiles" target) (needs
> additional setup)
> • MinGW with GCC 3.4.2 [Win32] ("MinGW Makefiles" target)
> • gcc 3.3.5 [Linux: Debian 3.1] ("Unix Makefiles" target)
> • gcc 4.0, 4.1, 4.2 [Linux: Debian 4.0] ("Unix Makefiles" target)
> • gcc 4.0 [Mac OS X 10.4.10] ("Unix Makefiles" target)
For Windows for instance, I don't even know, except maybe on an old dusty CD
out from the attic, where anybody might find a Visual C++ 9 (or 8!) and an OS
in good order to run it, build PoDoFo, and develop, build, test, deploy any
valuable application using it, with these outdated tools. On the computer-era
timeline, I'm a rather old man, born in the early 60', but believe me or not, I
have no nostalgia of the compiler tools we used by the end of the 20th century.
Not even those used more than a decade ago.
I'm NOT advocating to use cutting-edge C++ new goodies. Just to think about
deciding, setting in stone, that for now and some yet undefined future, PoDoFo
is based on C+11, a stable reasonable, old-enough, standard basis. So that any
line of code inside PoDoFo (and that includes its 'public' interfaces) could
make use of any language feature supported by C++11, when really appropriate to.
Switching from auto_ptr to unique_ptr would be more than enough as a valuable
first step in that direction.
:)
--
Best Regards, Meilleures salutations, Met vriendelijke groeten,
Olivier Mascia
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] std::auto_ptr --> std::unique_ptr
Dear all, Just an outsider view... Have the main contributors to the project finally made a decision about replacing std::auto_ptr by std::unique_ptr within PoDoFo source code and its public interfaces? std::unique_ptr has been introduced in the standard by C++11, and std::auto_ptr has been deprecated since. Then came C++14 and last year C++17 removed the deprecated std::auto_ptr. Projects using C++17 code need to patch PoDoFo source code and interfaces (by a replacing occurrences of std::auto_ptr by std::unique_ptr). That is not a terrible inconvenience, I agree. Anyway, it probably would be fairly conservative to decide and declare that PoDoFo code relies on C++11 and requires a C++11 compliant compiler. Then it wouldn't be an issue to migrate the code to std::unique_ptr. And to take care not to rely on anything else clearly deprecated by C++11, 14 and 17. Just a matter of looking forward instead of behind, I think. Are there really, in the eve of year 2019, users expecting to compile PoDoFo or use PoDoFo from C++ environments not meeting C++11 compliance, or at least the introduction of std::unique_ptr which had started to be supported by some compilers even before C++11 had turned standard? -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Font subsetting is producing invalid PDF
> Le 13 nov. 2018 à 23:51, Michal Sudolsky a écrit : > > Also if you are sending generated pdf files over network would not be better > to write them directly into memory and circumvent slow filesystem? Thanks for your other discoveries about the failure to embed in some cases. Regarding your hint about saving to memory for my use case (and though this is of topic), it generally makes sense but no it is not better for this use case. Produced files can be large, there is no advantage to pipe a single PDF of 1000+ pages to memory (in addition to transient PoDoFo memory needs while building those files) before transmitting over the network. The disk save is negligible in regards to the network transmission and the network transmission used is optimised for pushing files anyway (virtual memory mapping of files to be sent). We have zero bottleneck there due to building PDF on disk. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Font subsetting is producing invalid PDF
> Le 13 nov. 2018 à 18:46, Michal Sudolsky a écrit :
>
> Whether I use this:
>
> PdfDocument::CreateFontSubset("Arial", false, false);
>
> Or this:
>
> PdfDocument::CreateFont("Arial", false, false, false,
> PdfEncodingFactory::GlobalWinAnsiEncodingInstance(),
> PdfFontCache::eFontCreationFlags_Type1Subsetting);
>
> It produces invalid pdf. Acrobat says "The font 'AA+ArialMT' contains bad
> /Widths." and indeed it does not have widths:
>
> 19 0
> obj< 20 0 R/Subtype/TrueType>>
For what it's worth (as a user of PoDoFo 0.9.5) I use the following code to
embed Consolas:
PdfDocument::CreateFontSubset("Consolas", false, false, false,
PdfEncodingFactory::GlobalIdentityEncodingInstance());
And for Arial which is ubiquitous, I simply do not embed it, quite successfully
with :
PdfDocument::CreateFont("Arial", false, false, false,
PdfEncodingFactory::GlobalWinAnsiEncodingInstance(),
PdfFontCache::eFontCreationFlags_AutoSelectBase14,
false /* Don't embed */);
I must say and admit my use case is somewhat specific because those PDFs are
built by some process, transmitted over the network to another one, which will
display them or print them. The whole production of PDF is used as an
intermediate medium between one remote non interactive part of the software and
a GUI part running on other systems, which contains display and printing
capabilities. So that the remote non interactive part can build printed
reports, even to be physically printed the next second by the GUI component, in
full abstraction of any knowledge of the printer or display devices (except the
page format).
I don't exactly remember, why I had to choose GlobalIdentityEncodingInstance()
for CreateFontSubset.
--
Best Regards, Meilleures salutations, Met vriendelijke groeten,
Olivier Mascia
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Patch to handle indirect ID in trailer
> Le 1 nov. 2018 à 11:09, zyx a écrit : > > On Wed, 2018-10-31 at 23:14 +0100, Matthew Brincke wrote: >> IHMO yes, because if it were encrypted, an indirect ID would be >> against the PDF standard, right? I think that should be caught ... > > Hi, > even it would be against the standard, PoDoFo is not a validator, it > might not panic if some software creates documents which are not > following the standard strictly. Personally, I'd relax more checks in > PoDoFo, allowing to read broken files as much as possible, rather than > reject to read the file completely. That's only my opinion though. > Bye, > zyx +1. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] RC1 - Windows builds 'PODOFO_VERSION_PATCH" value
Hello, For your information, this: SET(PODOFO_VERSION_PATCH "6-rc1" CACHE STRING "Patchlevel part of PoDoFo version number") breaks resource compiling for Windows builds because the value "6-rc1" is not numeric. (Easy enough for me to patch only locally for purpose of building, but wanted to report). -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Patch 'size matters 32/64' based on rev #1898
> Le 1 mars 2018 à 11:31, Olivier Mascia <o...@integral.be> a écrit : > >> this introduces new compiler warning in podofosign (interestingly only >> at this place, good job): >> >> podofosign.cpp: In function ‘void >> sign_with_signer(PoDoFo::PdfSignOutputDevice&, X509*, EVP_PKEY*)’: >> podofosign.cpp:226:16: warning: comparison between signed and unsigned >> integer expressions [-Wsign-compare] > > Will recheck and adjust podofosign.cpp. From my initially submitted patch, you should filter out the lines about podofosign.cpp and replace by this patch still based on #1898. Should be cleaner on multi-platforms / memory models. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia podofosign.cpp.patch Description: Binary data -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Patch 'size matters 32/64' based on rev #1898
> On Tue, 2018-02-27 at 16:54 +0100, zyx wrote: > > this introduces new compiler warning in podofosign (interestingly > > only at this place, good job): > > Hi again, > I forgot to add, I do not think that implicit casts cause any real > issue, compilers are able to claim warnings when it's a problem these > days, thus it should be better to address them, than to hunt for > static_cast<>-s or anything like that, which can work for the external > library API of version X, but would cause similar casts with version Y > (like when the API changes between X and Y). > > There are surely issues with higher priority and higher impact than > this (not that having a clean code is a wrong thing, it's the opposite; > compilers usually do know why they claim certain issues and having the > code without compiler warnings is a good goal to achieve). > > Just my opinion. Zyx, /Replying out of thread (because I didn't receive some posts to the list - sourceforge using various servers for sending and some have PTR records awfully configured - fixed it on my side now, I guess)./ Indeed. For now, such hunts are the only contributions I can do for the project. :) > this introduces new compiler warning in podofosign (interestingly only > at this place, good job): > >podofosign.cpp: In function ‘void > sign_with_signer(PoDoFo::PdfSignOutputDevice&, X509*, EVP_PKEY*)’: >podofosign.cpp:226:16: warning: comparison between signed and unsigned > integer expressions [-Wsign-compare] Will recheck and adjust podofosign.cpp. I agree the addition of static_cast in most places is not of great importance - nor urgent in any way, except to hide those warnings confirmed to be non-significant, such that when other warnings re-appear they are more likely to trigger attention. When you get used to see, and ignore, tens or hundreds of insignificant warnings on each build, it is harder to spot those that should trigger real concern. The patch also has some other kind of fixes: at some places it was a matter of selecting a better type for some variable, to eliminate the need for any cast. And there are the recent printf format string changes : at some places it now expects a 64 bits value (due to the format specifier) and some arguments are 32 bits when compiling in 32 bits mode (size_t returned from strlen for instance), that's why the static_cast are needed (really) in those places. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] Fwd: Patch 'size matters 32/64' based on rev #1898
> De: Olivier Mascia <o...@integral.be> > Objet: Patch 'size matters 32/64' based on rev #1898 > Date: 27 février 2018 à 15:13:35 UTC+1 > À: podofo-users@lists.sourceforge.net > > Please consider this patch to resolve a number of 32/64 implicit conversions > which most probably trigger (without this patch) a good number of warnings > from various 32 and 64 bits compilers. > ... Dear all, As I did not receive echo of this above post to the list... Could some of you confirm wether it reached the list, or not ? I'm not expecting any followup or reaction from that patch proposal: I'm just trying to make sure it DID reach the list. Thanks and sorry for the noise if I'm the only one not receiving (sometimes it works, sometimes not) his/her own posts back from the list processor, -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] Testing email flow through sourceforge...
Please excuse - and ignore - this test message. It looks like sourceforge has a lot of weird technical issues these last weeks. Emails do not seem to be flowing through this list, at least deterministically. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] Patch 'size matters 32/64' based on rev #1898
Please consider this patch to resolve a number of 32/64 implicit conversions which most probably trigger (without this patch) a good number of warnings from various 32 and 64 bits compilers. This patch does not cover at all smaller size checks (implicit conversions from 32/16 to 16/8 for instance like int to char), it focuses only on the usual discrepancies seen in code needing to be correct for 32 and 64 bits, without raising needless alarms. The usual stuff arising from int, size_t, streamoff not having the same relation one to another in 32 bits or 64 bits models. Some of these fixups would better be made by changing some methods signature, but I didn't wanted to get on a sloppy way, as I'm not yet fully used to PoDoFo code base. Overall, this consist of some static_cast<> as appropriate to match a value to what a system library or dependant library expect as a parameter. Sometimes the fix is done by changing the type of a local variable (some int becoming size_t for instance). I chose the path of least changes when given the opportunity. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia size-32-64-rev1898.patch Description: Binary data -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] Proposed patch regarding printf formats incorrect for 64 bits
Hello, I'm attaching a small portability patch correcting some format strings that should use PDF_FORMAT_INT64 or PDF_FORMAT_UINT64 instead of "lu" or "li" when the argument is 64 bits wide. Most of them are in debug messages, though not all. These were spotted doing 64 bits builds using Visual Studio 2017 v15.5.4. Please review and use or adjust to your liking. There are also a good number of warnings about implicit size casting from 64 bits to 32 bits. I have yet to review them one by one, when time will permit. The usual problem is that most, if not all, are most probably insignificant, but you can't never be sure there is not a real issue lying behind one. Most of them come from size_t becoming int or unsigned, for instance strlen() returning size_t then used as an unsigned (int). Yet, some are related to double / float. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia printf-64bits.patch Description: Binary data -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Watermarks?
> Le 22 févr. 2018 à 21:47, Matthew Brincke <ma...@mailbox.org> a écrit : > >> How about watermarking pages? >> Either with text, images or PDF pages? >> > I'm no expert for "watermarking", especially about securing/hardening > against removal of such a watermark (e.g. e-books marked with customer data). No need for such securing for what I want to do. My use of the word "watermarking" was misleading. :) >> I mean, take two existing PDF files A and B. >> Update file A, placing content of page B.2 so it displays underneath >> (or over) page A.1 existing content? >> >> Or given PDF file A, add text or images underneath (or over) page A.2? > Ah, that is meant: If there's any problem doing that with PoDoFo, it's the > latter's bug ;-). Just append the page's stream to the watermark's (what > comes later draws over the preceding content). In case graphics settings > could be changed in a page without reset: call PdfPainter::Save() first > (on an empty page, which has to be set first), then PdfPainter::GetCanvas(), > append the background's content's stream PdfPage::GetContents()->GetStream() > to the former's return object, call PdfPainter::Restore(), then append the > foreground likewise, call PdfPainter::FinishPage() (is automatically called > by SetPage()) and you should be set (sorry, I haven't tested this yet with > a current revision of PoDoFo, so please report any oddities you see). > >> >> Is there any known piece of code (even pseudo code of course or just some >> explanations) which would give pointers on how to achieve this using PoDoFo >> or building it around PoDoFo? > > Please see above for an explanation/recipe. I hope this helps you. The whole picture seems perfectly clear!! Many many thanks. I'll experiment on sat/sun. I'll share any oddities I might find, hoping it won't be mistakes on my side. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] Watermarks?
Dear all, How about watermarking pages? Either with text, images or PDF pages? I mean, take two existing PDF files A and B. Update file A, placing content of page B.2 so it displays underneath (or over) page A.1 existing content? Or given PDF file A, add text or images underneath (or over) page A.2? Is there any known piece of code (even pseudo code of course or just some explanations) which would give pointers on how to achieve this using PoDoFo or building it around PoDoFo? Thanks, -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Accessing the images of one page?
> Le 21 févr. 2018 à 18:02, Dmitry Salychev <darkness@gmail.com> a écrit : > > Olivier, > > ah, I see. > Anyway, your idea is to get any PDF file, scan it page by page and perform an > action if there is a specific image (QR code) placed on any page. > Am I correct. ? Precisely, yes. That’s something I do today using another toolkit than PoDoFo, but I would like to switch to PoDoFo for the future. -- Best regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia (from mobile device) smime.p7s Description: S/MIME cryptographic signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] non-free piece of code in src/base/PdfString.cpp
Replying to: https://sourceforge.net/p/podofo/mailman/message/35633858/ (Which I read from the archives as I wasn't subscribed to this list by that time) Not sure if it would fit your complete needs, along with licensing needs, but you might want to have a look to: http://utfcpp.sourceforge.net https://sourceforge.net/projects/utfcpp/ > A simple, portable and lightweight generic library for handling UTF-8 encoded > strings. > > Features > • Iterating through UTF-8 encoded strings > • Converting between UTF-8 and UTF-16/UTF-32 > • Detecting invalid UTF-8 sequences The license looks MIT-like to me. > // Copyright 2006 Nemanja Trifunovic > > /* > Permission is hereby granted, free of charge, to any person or organization > obtaining a copy of the software and accompanying documentation covered by > this license (the "Software") to use, reproduce, display, distribute, > execute, and transmit the Software, and to prepare derivative works of the > Software, and to permit third-parties to whom the Software is furnished to > do so, all subject to the following: > > The copyright notices in the Software and this entire statement, including > the above license grant, this restriction and the following disclaimer, > must be included in all copies of the Software, in whole or in part, and > all derivative works of the Software, unless such copies or derivative > works are solely in the form of machine-executable object code generated by > a source language processor. > > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT > SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE > FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE, > ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > DEALINGS IN THE SOFTWARE. > */ -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] Accessing the images of one page?
Dear all, The podofoimgextract tool is a good documentation on how to access all images in a PDF file. What I would like to do is access all the images used on one page. I'm a bit short on documentation or sample code to get inspiration, short of reading the Adobe PDF standard, I suppose. :) To understand the context, the purpose is to scan for QR barcodes on each page and act on that page when found. The QR side is not an issue. I'm just hardly finding my way on how to properly enumerate the images used on a page instead of browsing all the images as a whole without consideration on which page it is used. It probably is incredibly simple to do using the primitives of PoDoFo, but I'm still struggling learning it deeper than at its surface. If you know of a bit of code or merely a bit of documentation which might be useful for me to read, I'm all ears. Thanks a lot, -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] std::auto_ptr
> Le 8 févr. 2018 à 12:06, Olivier Mascia <o...@integral.be> a écrit : > > Dear, > > That may have been changed since 0.9.5 code base released, but it might be > good to replace all uses of std::auto_ptr with std::unique_ptr (which has > been here since C++11 and possibly earlier in some compilers), while auto_ptr > has been deprecated since C++11 and more annoyingly *removed* since C++17. > > http://en.cppreference.com/w/cpp/memory/auto_ptr > http://en.cppreference.com/w/cpp/memory/unique_ptr Understanding PoDoFo wants to stay compatible with historic compilers not even being C++11 compliant, what should be done regarding CMake and PoDoFo source code to conditionally use "std::unique_ptr" instead of "std::auto_ptr" based on the compiler being >= C++11 (which deprecated auto_ptr and replaced it by unique_ptr, or maybe based on C++17 which dropped std::auto_ptr (requiring to patch the source - easy replace, no semantic changes between these two, to be able to compile)? I currently simply do a replace all on each subversion update. I'm fine with that. Time passing by, some others might become tired of it. I'm virgin regarding CMake to the point that I couldn't get it to succeed configuring the project for me (on Windows x64, MSVC 2017) and found it much simpler to rebuild a Solution/Project by myself. It was easy understanding what files were needed for what through the CMakefiles.txt. This to say I'm not best suited for helping in reconfiguring CMake files for this C++11/17 detection. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] CreateFontSubset / Windows / TTF / IdentityEncoding / WinAnsiEncoding
Dear all,
I hit a font subsetting issue while starting discovering feature-set of PoDoFo
over these last days.
Essentially it can summarised as this:
...CreateFontSubset("Consolas", false, false); // using default
WinAnsiEncoding
...
...DrawText(56.69, top - 56.69, "Some text... 0123456789!");
leads to wrong PDF files being produced. It works with some fonts like 'Arial'
and 'Courier new' (though limited testing, so not sure it really works 100%).
It produces PDF files with display problems (varying effect depending on the
reader program) with at least 'Consolas' and 'Cambria'.
I just found out that using:
CreateFontSubset("Consolas", false, false, false,
PdfEncodingFactory::GlobalIdentityEncodingInstance());
It apparently works just fine (again not yet 100% tested but at least I'm not
seeing anymore issues with those tests). I can't anymore pass plain strings to
DrawText() and AddText, because the WinAnsi encoding of those strings are then
misinterpreted. But I found out that if I pass UTF-8 strings by taking care of
presenting them as pdf_utf8*, I can print things like "Some text... école
100,00€... 0123456789!" without problem.
It also works if I merely pass Windows wide chars (UTF-16) as L"Some text...
école 100,00€... 0123456789!"... But only if using IdentityEncoding.
I will now be able to push my tests of the library further.
Though, what's the known status of font subsetting with PoDoFo?
Is it expected that it would only work (apparently) correctly (or more
correctly) with IdentifyEncoding but not WinAnsiEncoding which is the default
for PoDoFo?
Info: when displaying file properties with Adobe Reader, and using
IdentityEnconding, the fonts are reported as:
Type: TrueType (CID)
Encoding: Identity-H
When using WinAnsiEncoding, which leads to my files being wrong, they are
reported as:
Type: TrueType(no mention of CID)
Encoding: ANSI
Don't know if that brings some light.
--
Best Regards, Meilleures salutations, Met vriendelijke groeten,
Olivier Mascia
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo and (TTF) fonts on Windows - new user
> Le 9 févr. 2018 à 16:05, Olivier Mascia <o...@integral.be> a écrit : > >> If I open your pdf in Acrobat I can get a inventory report. This shows on >> page 3 a missing ! in your cambria subset font, and some messages >> >> Uli > > Thanks a lot Ulrich for the time you took having a look and running this > report! Much appreciated. :) > This information confirms where I should be looking: some font subsetting > issue. > Now I have to find if this happens when PoDoFo writes to the PDF streams or > it it happens before, when FreeType gather the needed information. > At least it confirms there is value to dig that path. For information to whoever would feel alerted on this topic: in order to try to rule out FreeType lib out of the equation and eventually pinpoint defects in my build of FreeType which list an awful lot of size discrepancies warning when building for 64 bits, I tested using a prebuilt FreeType 2.7.1 library available from https://github.com/ubawurinna/freetype-windows-binaries as pointed to by https://www.freetype.org/download.html and I get the very exact same results from my tests. Logic dictates that this does not 100% rule out FreeType from this issue I see, of course, but it kind of tend to raise the suspect on PoDoFo code itself. That C++ code is more understandable / less cryptic to me, so I hope to debug this easier or reveal one possible defect in my build procedure or interaction with my compiler toolkit (Visual Studio 2017 version 15.5.4). -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo and (TTF) fonts on Windows - new user
> Le 9 févr. 2018 à 14:16, Ulrich Arnold Privat <ulrich.arn...@t-online.de> a > écrit : > > If I open your pdf in Acrobat I can get a inventory report. This shows on > page 3 a missing ! in your cambria subset font, and some messages > > Uli Thanks a lot Ulrich for the time you took having a look and running this report! Much appreciated. :) This information confirms where I should be looking: some font subsetting issue. Now I have to find if this happens when PoDoFo writes to the PDF streams or it it happens before, when FreeType gather the needed information. At least it confirms there is value to dig that path. Again, thanks! -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo and (TTF) fonts on Windows - new user
Dear,
> Le 8 févr. 2018 à 13:18, Olivier Mascia <o...@integral.be> a écrit :
>
>> Le 8 févr. 2018 à 11:33, Olivier Mascia <o...@integral.be> a écrit :
>>
>> ...
>> PdfFont* pFont = document.CreateFontSubset("Arial", false, false);
>> ...
>> the file looks good, Acrobat Reader and Mac Preview confirms ArialMT
>> partially embedded, no substitution done for display.
>> ...
>> Using CreateFontSubset("Consolas", false, false);
>> It displays white (no text visible at all) on Acrobat and partially on the
>> Mac Preview app (only the text "Accentués... Chiffres" but not the digits
>> themselves), yet Acrobat confirms "Consolas, partial embedding, Truetype, no
>> substitution", just as it did for Arial.
>>
>> I don't know yet what goes wrong. Is it the subsetting which goes wrong?
>> Does it go wrong due to whatever specifics in the Consolas font (which I
>> don't know/suspect about)?
>
> New facts, in case it would pop an idea, a déjà-vu, from one subscriber of
> the list.
>
> - rebuilt test case with code from subversion trunk : same results.
> - rerun same case with 'Courier New' instead of 'Consolas' : works fine,
> nothing strange spotted (just as it was fine with 'Arial').
> - rerun (the equivalent code) with another PDF toolkit than PoDoFo : works
> fine, nothing strange spotted (Arial, Courier New, Consolas, all fine).
> - checked on another one of my Windows VM (other Windows version), same
> results (only fails with 'Consolas'; maybe fails with some others too but I
> played only with Arial, Consolas, Courier New).
>
> I tend to think this rules out the state of my Consolas TTF font (which were
> not added / installed but are default provided on recent Windows versions,
> for years): that should not be originated in a bad / damaged file. Yet that
> could be something peculiar to that font (but what?) which leads PoDoFo doing
> something wrong (while some other toolkit seem not to have issue with that
> font).
>
> I'll have to get in and understand the code that drives the subsetting and
> injection of a TTF font into the PDF, tracing it with Arial and Consolas to
> maybe spot where it diverges.
I'm running in circles with this.
I have since found that using "Cambria" instead of "Consolas" also trigger
issues.
I have posted a small sample file (3 lines of text) :
(test.pdf) https://sea.tipintegral.net/f/41a14f24038947b6aa36/
The web display of the PDF on that interface (Seafile) looks nearly fine, but
it misses the "!" right after the digits on the line in Cambria.
If I download it and open it with Adobe Reader on Mac, it is the whole line in
Cambria which does not display.
With the Preview app on Mac, the result is similar to the one through the web
preview of Seafile.
So there is a problem, for sure.
My hope is that if some of you are kind enough and willing to download this
test.pdf file, he/she might confirm the display is also incorrect for them, and
maybe someone will pinpoint some technical detail in the file itself (the
internals of PDF are still remote for me) that could hint at a direction for me
to debug this. I'm trying to think backward: going from facts in the resulting
file to walk up to the possible source of it.
The line with "Arial" is set for NO embedding (if it's wrong for display for
you because Arial is not available to your viewer, please ignore, this is not
what I'm after).
PdfFont* pFont1 = document.CreateFont("Arial", false,
PdfEncodingFactory::GlobalWinAnsiEncodingInstance(),
PdfFontCache::eFontCreationFlags_AutoSelectBase14,
false);
The lines with "Cambria" and "Courier New" are set for subsetting.
PdfFont* pFont2 = document.CreateFontSubset("Cambria", false, false);
PdfFont* pFont3 = document.CreateFontSubset("Courier New", false,
false);
And here are the lines of code producing those small text samples:
...
pFont1->SetFontSize(15.0);
painter.SetFont(pFont1);
painter.DrawText(56.69, top - 56.69, "Arial not embedded... Chiffres
0123456789!");
pFont2->SetFontSize(15.0);
painter.SetFont(pFont2);
painter.DrawText(56.69, top - 2*56.69, "Cambria partial... Chiffres
0123456789!");
pFont3->SetFontSize(15.0);
painter.SetFont(pFont3);
painter.DrawText(56.69, top - 4 * 56.69, "Courier New partial...
Chiffres 0123456789!");
...
I'm willing and generally not bad at debugging things in code I'm not familiar
with, but need a hint, a starting point, a clue to focus the search... :)
By all m
[Podofo-users] Which FreeType library version should PoDoFo (trunk code) use?
Dear, Which FreeType library version should PoDoFo (trunk code) use? Is it known to be OK to use the 2.9 or should we stick to something older like 2.8 series? As I happen to have started evaluating PoDoFo this week and had no FreeType library on my systems (Windows), I went straight and build the last released one I found through freetype.org, without really spotting the 2.9 was so 'fresh' (January 2018). And as I have found some oddity with subsetting of one font (discussed in another thread) and I see that FreeType library is involved in that process, I'm wondering wether I painted myself in a corner. :) -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo and (TTF) fonts on Windows - new user
> Le 8 févr. 2018 à 11:33, Olivier Mascia <o...@integral.be> a écrit :
>
> ...
> PdfFont* pFont = document.CreateFontSubset("Arial", false, false);
> ...
> the file looks good, Acrobat Reader and Mac Preview confirms ArialMT
> partially embedded, no substitution done for display.
> ...
> Using CreateFontSubset("Consolas", false, false);
> It displays white (no text visible at all) on Acrobat and partially on the
> Mac Preview app (only the text "Accentués... Chiffres" but not the digits
> themselves), yet Acrobat confirms "Consolas, partial embedding, Truetype, no
> substitution", just as it did for Arial.
>
> I don't know yet what goes wrong. Is it the subsetting which goes wrong? Does
> it go wrong due to whatever specifics in the Consolas font (which I don't
> know/suspect about)?
New facts, in case it would pop an idea, a déjà-vu, from one subscriber of the
list.
- rebuilt test case with code from subversion trunk : same results.
- rerun same case with 'Courier New' instead of 'Consolas' : works fine,
nothing strange spotted (just as it was fine with 'Arial').
- rerun (the equivalent code) with another PDF toolkit than PoDoFo : works
fine, nothing strange spotted (Arial, Courier New, Consolas, all fine).
- checked on another one of my Windows VM (other Windows version), same results
(only fails with 'Consolas'; maybe fails with some others too but I played only
with Arial, Consolas, Courier New).
I tend to think this rules out the state of my Consolas TTF font (which were
not added / installed but are default provided on recent Windows versions, for
years): that should not be originated in a bad / damaged file. Yet that could
be something peculiar to that font (but what?) which leads PoDoFo doing
something wrong (while some other toolkit seem not to have issue with that
font).
I'll have to get in and understand the code that drives the subsetting and
injection of a TTF font into the PDF, tracing it with Arial and Consolas to
maybe spot where it diverges.
--
Best Regards, Meilleures salutations, Met vriendelijke groeten,
Olivier Mascia
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] PdfString::ConvertUTF8toUTF16 - unreachable code
PdfString::ConvertUTF8toUTF16 has this sequence of code with a comment from
'RG' about compiler complaining about unreachable code:
} else if (ch > UNI_MAX_UTF16) {
if (eConversion == ePdfStringConversion_Strict) {
PODOFO_RAISE_ERROR( ePdfError_InvalidDataType );
//RG: TODO My compiler says that this is unreachable code!
source -= (extraBytesToRead+1); /* return to the start */
break; /* Bail out; shouldn't continue */
} else {
*target++ = UNI_REPLACEMENT_CHAR;
}
} else {
It only is because PODOFO_RAISE_ERROR is actually "throw ::PoDoFo::PdfError".
The code after that is actually unreachable, because of the throw. I haven't
yet get deeper to understand what was the real intent here. If someone is
familiar with that method implementation, he/she'll know what to do right.
--
Best Regards, Meilleures salutations, Met vriendelijke groeten,
Olivier Mascia
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo and (TTF) fonts on Windows - new user
Thanks for your answers, > Le 8 févr. 2018 à 11:58, zyx <z...@gmx.us> a écrit : > > See the prototype of the CreateFont() function, the last argument there > says whether to embed the font or not. The default is to embed it. The > subset-ed fonts are always embedded. Got it. Works nice. > Regarding the used C++ standard, the 0.9.5 has bug where when the > PoDoFo had been compiled with a different C++ standard than the > application using it, then it could cause undefined behaviour. This is > fixed with the svn trunk, thus I suggest you to use the trunk snapshot, > instead of that old release. There is planned 0.9.6 release in several > weeks, which will be based on this trunk source code (thus some early > testing will be also appreciated). I carefully build PoDoFo exactly as I build the host application (same compiler, same settings, up to PoDoFo dependencies too - jpeg, png, tiff, freetype). But I will anyway soon checkout the trunk code and reboot my testings from that. > I've no answer for your "Consolas" font problem. I'll get deeper by testing further with other well-known fonts on Windows like "Courier New" (which might be a poor replacement for Consolas). And retesting again with trunk code. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] std::auto_ptr
Dear, That may have been changed since 0.9.5 code base released, but it might be good to replace all uses of std::auto_ptr with std::unique_ptr (which has been here since C++11 and possibly earlier in some compilers), while auto_ptr has been deprecated since C++11 and more annoyingly *removed* since C++17. http://en.cppreference.com/w/cpp/memory/auto_ptr http://en.cppreference.com/w/cpp/memory/unique_ptr I had to build with a C++17 setup and these were the only errors encountered. The remaining unclear bits are only warnings which I still need to investigate. What this experience means is that PoDoFo C++ coding is very good. :) -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] PODOFO_MULTI_THREAD
Hello, Just for confirmation from people used to PoDoFo, am I right thinking that I don't need to define PODOFO_MULTI_THREAD, so that PdfMutexImpl_noop.h gets used instead of implementing a real mutex, as long as I never ever handle a same document (or any other resource) from multiple threads? Or should I define it (has been done since my first build) anyway as Lon as the host application is multi-threaded and could write (different) documents from different threads? Shared font caching between threads maybe? Or something else? Until I get the time to learn the code better, I am for keeping that turned on, unless I learn otherwise from this list. :) -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] PoDoFo and (TTF) fonts on Windows - new user
Hello,
I am starting some experiments with PoDoFo 0.9.5 on Windows. I'd say that for
what I saw of the code, peeking at it while preparing it to build in my
environment, it looks very good, and it seems to cover all my needs.
Though very initial tests reveal something that might prove complex to
overcome, unless I am making something awfully wrong (on this platform -
Windows).
Using this test code, which is essentially the short demo code:
using namespace PoDoFo;
PdfStreamedDocument document("test.pdf");
PdfPage* pPage =
document.CreatePage(PdfPage::CreateStandardPageSize(ePdfPageSize_A4));
PdfFont* pFont = document.CreateFont("Arial");
pFont->SetFontSize(18.0);
PdfPainter painter;
painter.SetPage(pPage);
painter.SetFont(pFont);
painter.DrawText(56.69, pPage->GetPageSize().GetHeight() - 56.69,
"Accentués... Chiffres 0123456789!");
painter.FinishPage();
document.GetInfo()->SetTitle(PdfString("Hello World"));
document.Close();
(A)
(A.1) I get a test.pdf of 535 KB (!). It renders good, and Adobe Reader
confirms ArialMT embedded (which explains the size of the file). But I have to
produce smaller files than that.
(A.2) So to test subsetting, I replace the above CreateFont() by:
PdfFont* pFont = document.CreateFontSubset("Arial", false, false);
Now the test.pdf file is between 16 and 17 KB. The size shrinks heavily on
this test containing very few characters, that's expected. Again the file looks
good, Acrobat Reader and Mac Preview confirms ArialMT partially embedded, no
substitution done for display.
[ Side note: I'm writing code on Windows, but regarding PDF output I always
test / assess their output validity / quality on Mac with Adobe Reader and
macOS Preview App. If my Windows produced files do the job when displayed or
printer there, they most probably are good for use. :) ]
(B)
Now I'm running the same tests with "Consolas".
(B.1) With CreateFont("Consolas") the file is about 250 KB. It renders good
(just as with Arial) and nothing suspect in the font properties displayed by
Acrobat.
(B.2) Using CreateFontSubset("Consolas", false, false);
The file is about 12 KB.
But it displays white (no text visible at all) on Acrobat and partially on the
Mac Preview app (only the text "Accentués... Chiffres" but not the digits
themselves), yet Acrobat confirms "Consolas, partial embedding, Truetype, no
substitution", just as it did for Arial.
I don't know yet what goes wrong. Is it the subsetting which goes wrong? Does
it go wrong due to whatever specifics in the Consolas font (which I don't
know/suspect about)?
What path would you suggest me to follow to get deeper on this?
(C)
What steps should I take to NOT embed a font at all (knowing the consequences
of it being substituted right or wrong on display/print)?
I sometimes like to not embed at all because I control the process which builds
the file, sends it away and the process that receives it and prints it and both
*have* available the fonts that I selectively choose not to embed. The
advantage is the file produced is *very* small (should be about 1 to 2 KB for
the above test snippet, using other PDF writing tools as a comparison).
Aside from this I spotted some C++ details, while using a C++14 and a C++17
environment, which you might want to consider adjusting (if not already done in
trunk: I'm using the 0.9.5 archive, not checking out subversion yet). I'll
write another post about these C++ details a bit later.
Thanks a lot for any comment or hint anyone could offer to help get these first
steps. I have used other libraries over these last years for this kind of work,
so I know a small bit about these matters, just need to get properly acquainted
with PoDoFo specifics. Switching to PoDoFo would simplify some things for me:
because it apparently offers all the features for which I need different
libraries today, and because it is written in C++, like any other code I emit.
--
Best Regards, Meilleures salutations, Met vriendelijke groeten,
Olivier Mascia
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
