[Podofo-users] Suggested API cleanings [WAS: Status update]
Hello, 1.0 TODO[1] list clearing is proceeding steadily, with some tasks moved to post 1.0, as the focus now is shipping a sustainable stable API. Stable API does not mean the API can't possibly break more in the future, but the better we do the cleaning now the less chance that this will happen, as the bar for deprecation of methods will be raised. I wanted to ask if there are suggestions for more cleanings as when the 1.0 TODO list is empty then release will be on sight. Please don't suggest new features, only cleanings/small improvements to existing ones, if you think they are really worth and may be harder to fix after the stable API is shipped. Also please look at the current state of the source first, as the suggestion must fit with the current API design style (which I hope it should be clear enough looking at the code). Other than API cleanings, a flow of bugfixes is being pushed these days. I'm sorry some of these fixes regard features like font substitution/embedding or content stream editing that are not publicly tested yet. I hope I can make a meaningful unit test of these soon, at least to have some API usage examples. Greetings, Francesco [1] https://github.com/podofo/podofo/blob/master/TODO.md ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Loading pdfs with large number of trailers / updates causes stack overflow
Hello, thank you for the fixture, I can reproduce in Windows. With a test case fixing the bug becomes less "guess work" and more fun. Unfortunately I'm still in a period where I have little time to spend on PoDoFo in tasks that are not part of my daily work. If nobody takes it in the mean time, I think I may have time to look at it in a couple of weeks. Regards. Francesco On Thu, 1 Feb 2024 at 19:07, F. E. wrote: > Hello again, > > using a ps script, I successfully created an empty pdf with 160 trailers. > The trailers are all empty and do not change any objects, but reference > each other via /Prev, which is sufficient for the stack overflow to happen. > > Feel free to test the parsing with it :) > > Regards, > F.E. > > Am Do., 1. Feb. 2024 um 07:58 Uhr schrieb F. E. : > >> "think the matter is complex enough that this may undermine the chances a >> complete fix materializes soon. Also if you or someone else come up with a >> fix it would be recommendable for such SO related issue to add a unit test >> on an anonymized file that shows the same or very similar behavior." >> >> All thats needed is an example pdf with a massive amount of trailers / >> updates, it does not have to be my specific file. I know one can open a pdf >> in update-only mode with Podofo, I just don't know what the easiest way to >> apply an update would be. Maybe such a pdf could even be crafted manually. >> I'll look into this in the coming days, and will share a file if I'm >> successful. >> >> Am Mi., 31. Jan. 2024 um 14:28 Uhr schrieb Francesco Pretto < >> cez...@gmail.com>: >> >>> On Tue, 30 Jan 2024 at 12:39, F. E. wrote: >>> >>>> I sadly cannot share the file I'm testing against, since it contains >>>> confidential data. >>>> >>> >>> I think the matter is complex enough that this may undermine the chances >>> a complete fix materializes soon. Also if you or someone else come up with >>> a fix it would be recommendable for such SO related issue to add a unit >>> test on an anonymized file that shows the same or very similar behavior. >>> >>> Francesco >>> >> ___ > Podofo-users mailing list > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users > ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Loading pdfs with large number of trailers / updates causes stack overflow
On Tue, 30 Jan 2024 at 12:39, F. E. wrote: > I sadly cannot share the file I'm testing against, since it contains > confidential data. > I think the matter is complex enough that this may undermine the chances a complete fix materializes soon. Also if you or someone else come up with a fix it would be recommendable for such SO related issue to add a unit test on an anonymized file that shows the same or very similar behavior. Francesco ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Loading pdfs with large number of trailers / updates causes stack overflow
On Tue, 30 Jan 2024 at 23:00, Michal Sudolsky wrote: > @Francesco Pretto maybe you could fix that in the new > podofo? Something like this could work for example (pseudocode): > Just to be crystal clear: if a patch materializes I'll be happy to review it but I'm currently having a severe lack of time and working on security related issues in PoDoFo isn't exactly in my top interests (as I clarified elsewhere), even though I fixed a bunch of these in the 0.10.x series (and in master as well). It would be interesting to know if @Mark Rogers had the chance to upgrade to >=0.10 and if he wants to comment on this issue, since he wrote most of the stack overflow tests/infrastructure in 0.9.x. Greetings, Francesco ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] Status update
Hello, long time without updates. A couple of critical bugfix versions, with 0.10.3[1] being the last one, were recently released. In the news 2 major open source users of PoDoFo were ported to 0.10.x, namely Calibre and Scribus. With recent bugfixing, functionalities that used to work in 0.9.x (eg. PdfStreamedDocument) are now working in master (still unreleased), meaning that there shouldn't be more reasons to continue using 0.9.x, other than the burden of conversion. We also have automatically generated documentation[2], even though I'm not currently looking too much at the quality of the output. Of the projects I hoped to continue working two stalled, that are1) working on tools and 2) pursue LGPL/MPL relicensing: I hope to continue to work at least on relicensing next year. Instead a new Pdf signing API[3] was introduced as I promised for quite some time and it's also unit tested[4]. Even though by default it does a basic signing of the document (using most recent standard PAdES-B), it is VERY powerful and can be easily extended to use external signing services and add attributes. A mention of it in the README is still pending. From now on, my focus will be on finalizing the API review and have a 1.0[5] release with a stable API. That is: every single method/class of the API that I haven't looked yet will be looked though for consistency and robustness of the API design. To not create more incompatible APIs, 0.11 probably will be not released. E.T.A. still not determined. That's all for now. Regards, Francesco [1] https://github.com/podofo/podofo/releases/tag/0.10.3 [2] https://podofo.github.io/podofo/documentation/ [3] https://github.com/podofo/podofo/blob/master/src/podofo/main/PdfSignerCms.h [4] https://github.com/podofo/podofo/blob/master/test/unit/SignatureTest.cpp [5] https://github.com/podofo/podofo/blob/master/TODO.md#10 ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Podofo 0.10.x migration question
On Tue, 18 Jul 2023 at 20:24, Sandro Mani wrote: > Only exception is attempting to > pass a monochrome image bit-buffer to PdfImage::SetData, which results > in a distorted image. Forgot to say: using PdfImage::SetData with a monocrome input would have been wrong since there's no monochrome pixel format to choose, only "PdfPixelFormat::Grayscale" which assumes 8 bits grayscale input image (not your case). Using PdfImageInfo is the correct path to support these images. ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Podofo 0.10.x migration question
On Tue, 18 Jul 2023 at 20:24, Sandro Mani wrote:
> Interestingly, I had to comment out info.Filters, or I would get a blank
> image (I suppose because it would be "double" flate decoded, as
> FlateDecode is already default as you wrote?).
>
I discovered a mistake in the intended semantics of PdfImageInfo. I
had to change the Filters member to nullable[1], so
that when nullptr it will encode everything with FlateDecode (before
and empty list would have stored everything uncompressed), and when
set it will treat the input stream as it was encoded with the supplied
filter list. This was the only possible behavior previously, meaning
"info.Filters = {PoDoFo::PdfFilterType::FlateDecode}" would have
assumed the input to be already FlateDecode compressed, which probably
it was not as per your report. This also means that commenting that
line in your code is just the right thing to do, even with last
commit[1] applied.
Regards,
Francesco
[1]
https://github.com/podofo/podofo/commit/45e0dc4f0e2f5958d819b0c8d2400e532b6dc69c
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Podofo 0.10.x migration question
On Sat, 15 Jul 2023 at 23:58, Sandro Mani wrote:
> deflate was implemented as follows [...]
>
> which I translated to 0.10.x as
>
> PoDoFo::PdfImageInfo info;
> info.Width = width;
> info.Height = height;
> info.ColorSpace = colorSpace; //
> PoDoFo::PdfColorSpace::DeviceRGB or PoDoFo::PdfColorSpace::DeviceGray
> info.BitsPerComponent = sampleSize; // 8 or 1
> info.Filters = {PoDoFo::PdfFilterType::FlateDecode};
> pdfImage->SetDataRaw(PoDoFo::bufferview(buf.data(),
> buf.size()), info);
>
I don't recommend doing this way for simple RGB/Gray input.
FlateDecode is the default compression for streams so you really
should just use the PdfImage::SetData(buffer, width, height, format,
scanLineSize) supplying proper image buffer input (these concepts are
the same in all graphics libraries). The library will default flate
encode the buffer.
> which however aborts here in
> PdfStreamedObjectStream::GetInputStream(PdfObject& obj) with
>
> PODOFO_RAISE_ERROR_INFO(PdfErrorCode::NotImplemented, "Unsupported
> reading from streamed object stream");
>
Please, don't use PdfStreamedDocument for now, use PdfMemDocument (see [1]).
> The CCITT code, [...]
> which I attempted to port to 0.10.x as
>
> PoDoFo::PdfDictionary decodeParams;
> decodeParams.AddKey("Columns",
> PoDoFo::PdfObject(int64_t(img.width(;
> decodeParams.AddKey("Rows",
> PoDoFo::PdfObject(int64_t(img.height(;
> decodeParams.AddKey("K", PoDoFo::PdfObject(int64_t(-1))); // K
> < 0 --- Pure two-dimensional encoding (Group 4)
> pdfImage->GetDictionary().AddKey("DecodeParms",
> PoDoFo::PdfObject(decodeParams));
> PoDoFo::PdfImageInfo info;
> info.Width = width;
> info.Height = height;
> info.ColorSpace = colorSpace;
> info.BitsPerComponent = sampleSize;
> info.Filters = {PoDoFo::PdfFilterType::CCITTFaxDecode};
> pdfImage->SetDataRaw(PoDoFo::bufferview(reinterpret_cast char*>(encoded), encodedLen), info);
>
Please, re-try with with PdfMemDocument. This is a valid use case for
PdfImage::SetDataRaw, maybe it could be improved so "DecodeParms" are
added along filters in PdfImageInfo structure.
[1] https://github.com/podofo/podofo/issues/88
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Podofo 0.10.x migration question
Are you trying to load a PdfImage from a jpeg image? If so, you should use PdfImage::LoadFromBuffer(buffer), which will automatically fill the image with the jpeg content. PdfImage::SetData(buffer, width, height, format) is specialized to load an image from raw pixel data, as the PdfPixelFormat enum parameter should have suggested. It's a new feature in 0.10.x. Other input definitions are supported through PdfImage::SetDataRaw(buffer, info), but not recommended for users that don't know what they are doing. On Fri, 14 Jul 2023 at 16:46, Sandro Mani wrote: > > Hi > > I'm migrating some podofo-0.9.x code to 0.10.x. I have code writing > encoded image streams like this: > > QByteArray data; > QBuffer buffer(); > img.save(, "jpg", settings.compressionQuality); > PoDoFo::PdfName > dctFilterName(PoDoFo::PdfFilterFactory::FilterTypeToName(PoDoFo::ePdfFilter_DCTDecode)); > pdfImage.GetObject()->GetDictionary().AddKey(PoDoFo::PdfName::KeyFilter, > dctFilterName); > PoDoFo::SpanStreamDevice is(data.data(), data.size()); > pdfImage->SetData(is, width, height, pixelFormat); > > which I'm having difficulties to adapt to 0.10.x as the API changed > substantially here. Can someone provide an example? > > Thanks > Sandro > > > > ___ > Podofo-users mailing list > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] PoDoFo 0.10.1 released
Hello, PoDoFo 0.10.x series got its first point release. This is the changelog: - Security bugfixes, #66, #67, #69, #70, #71, #72 - Rewritten PdfPageCollection for performance - PdfCMapEncoding: Fix parsing some invalid CMap(s) supported by Acrobat - PdfXRefStreamParserObject: Fixed handling of invalid XRef stream entries - Support compilation of the library header (not the library itself) with C++20 ... and more. It brings a huge performance improvement in PdfPageCollection, with >200 pages document requiring >3sec to just iterate pages moving to <100ms. PoDoFo 0.10.1 is almost API compatible with 0.10.0. A vulnerability bug fix[1] required to slightly change rarely used API (probably just an infrastructure method). It adds another ABI incompatibility because of the same vulnerability bug fix. In other news (future releases): - I am working on more (API incompatible) changes that will allow to decode more image types/colors paces. As a sad news, I found the design of PdfColor to be not good in the sense it both represents a storage for color characteristics and can define a new color space at the same time. This is not good as a class design, as information is not well organized, and will require changes; - As soon as work load (hopefully) decreases this summer I want to have a look at tools so they can be released again. Regards, Francesco [1] https://github.com/podofo/podofo/issues/70 ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Issue in Merging of some documents with error ePdfError_NoNumber
Hello, I'm considering the other post here[1] as a duplicate so I won't answer that. First of all 0.9.7 is part of the old 0.9.x code base and at this point it is unlikely it will receive bug fixing for non trivial, non critical issues. The code for page merging has not been reviewed for 0.10.x but I had a brief look at it and to my judgment is hacky and I would like to rewrite it at some point. It also not unit tested at all. There are other github issues[2][3] related to it: I can review small simple patches for obvious issues, even though the plan is to eventually fully rewrite the code. If this feature is critical for your PoDoFo workflow you may consider research the topic yourself and contribute[4] to PoDoFo your findings and code. Cheers, Francesco [1] https://www.mail-archive.com/podofo-users@lists.sourceforge.net/msg04959.html [2] https://github.com/podofo/podofo/issues/73 [3] https://github.com/podofo/podofo/issues/76 [4] https://github.com/podofo/podofo/#contributions On Thu, 1 Jun 2023 at 12:54, Vaibhav Kapil wrote: > > Hi , we are using a podofo version 0.9.7 and while merging some pdf files , > we get this error ePdfError_NoNumber . This does not happen for all > documents , but happens rarely for some of the documents. > Can someone tell me the fix for this or link a similar thread/issue where > this issue has been addressed. > Thanks ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Patch for PoDoFo Build 2033
Hello, you may be aware that PoDoFo repository has moved to github, also for 0.9.x[1] code. I'm sorry, I don't want to be involved with legacy code maintaining but I remember that before pushing PoDoFo-next (now 0.10.x) I actively reviewed a pull request for something that may be your exact issue[7], and the PR was eventually merged. Can you check and confirm it? Cheers, Francesco [1] https://github.com/podofo/podofo/tree/0.9.x [2] https://github.com/podofo/podofo/pull/7 On Tue, 16 May 2023 at 12:54, Ulrich Arnold wrote: > Hi! > > > > I think I found a small bug in the code for setting creation- and > modification-date. At least in the WIN32-branch daylight-saving-time is not > taken into account, resulting in Acrobat showing the time 1 hour off. > According to Pdf-Docs 1.7 chapter 7.9.4 the time format is local time > followed by the absolute difference to UTC. For Germany this would be +1h > due to time zone, but +2h during active daylight-saving-time. Attached is > the patch against build 2033. I don’t know, whether it is necessary in the > other branch as well. > > > > Regards Uli > > > ___ > Podofo-users mailing list > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users > ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo 0.10.0 released
On Mon, 27 Mar 2023 at 10:13, Francesco Pretto wrote: > 0.9.x -> 0.10.0 is a big break. [...] There's currently no 0.9.x -> 0.10.0 > migration guide. I added an incomplete 0.9.8 -> 0.10.0 migration guide[1]. Feel free to suggest improvements. Regards, Francesco [1] https://github.com/podofo/podofo/wiki/PoDoFo-API-migration-guide ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo 0.10.0 released
On Tue, 28 Mar 2023 at 07:25, zyx wrote: > I know Ogre3D > project used such a volunteer to modernize their examples and it was a > great success from my point of view. PoDoFo is not Ogre3D, of course. > Anyway, it was only an idea. > I understand, but get me right: we need tools sooner than the deadlines of the next initiative for internships. We could definitely submit applications for internships later for other interesting projects, eg. for the renderer, that is something I always have in mind. > Tools are good not only because you can just use them, they can be used > also as an example of how to use the project/API. You can have it also > as a test, even not automated, that the code does what it should do, on > real life data, not with artificial data. Tools have several benefits, > even you look on them as a maintenance burden. > Of course, and I already said that just mechanically porting the tools helped a lot in improving the revamped API. The problem I have with tools is that in some package managers they were packaged together with the library and this created an expectation that tools should be granted for being deployed together with the library. Also, I think some tools today don't reach the bar for the quality we can deliver with the PoDoFo library. For example: podofocrop[1] today is really just a wrapper around ghostscript. We provably have today the commodities to implement the same functionality with PoDoFo, but this requires a little bit of devotion to it. > I can test the podofo-sign, after all I added it. That's good. About this: I have in mind an high level signing API that may appear for 0.11. This means that at some point I may look at podofosign to use it. > No promise when it'll > be, I'm busy with some real life work at the moment (and for quite some > time), but I can do it if nobody will be quicker than me. > It's a starting point. I also have a full time job which is only partially focused on PDFs, and recent refactors (eg. PdfPianter) and release handling for 0.10.0 were done on my free time, but I understand what it does mean being busy with something else in personal/work life. To be clear, I'm deliberately putting some pressure on the ML to ask for some help in the hope of doing stuff quicker, but of course if we can't quickly find volunteers it's just fine: things will arrive, just a little bit later. Cheers, Francesco [1] https://github.com/podofo/podofo/blob/master/tools/podofocrop/podofocrop.cpp ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo 0.10.0 released
On Mon, 27 Mar 2023 at 07:34, zyx wrote: > > Would such task be attractive enough? > > I do not know. It would be seen when tried. I don't know, I am unconvinced because not doing this work and ask someone else outside of our community to do it smells like procrastinating, and we would just take the risk of crying later because we didn't find anybody that wanna do it. I will always stress that I am uninterested by tools, also because I would like to take responsibility for things I am confident I can do reasonably well, but if it helps I have no issue in volunteering for more work. I can: - Estimate the time needed to clean, modernize and re-test each tool. - Prepare the common infrastructure work I was suggesting; - Adopt a few ones (let say 4-5). The others should be adopted by someone else, at least temporarily. There are currently 19 tools, for a total of less than 6k of lines of code (which really it's nothing and I'm sure there's a lot of boilerplate too), with only a couple of tools that are "bigger" (podofocolor and podofoimpose), and the others really small or trivial. In 3-4 people we can divide the work and really in few days of work everything is done, even before summer. If not even in this way we can find enough volunteers then I question again why tools should be maintained at all: code lives because it's maintained and constantly improved, not just because you can find it compiled in Linux distributions. Let me know what you think about. Regards, Francesco ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo 0.10.0 released
On Mon, 27 Mar 2023 at 06:24, Daniel Macks wrote: > Could you clarify the nature of the API instability? 0.9.x -> 0.10.0 is a big break. Some early adopters were able to port to 0.10.0 with no/few questions. There's currently no 0.9.x -> 0.10.0 migration guide. We could still try to make one but that depends on time availability. The goal for 0.10.0 -> 1.0.0 is to reach a stable API: I expect breakings to be smaller and we should definitely report API breakings during the process. Because of the nature of C++, ABI stability is a non goal. > The usual library approach is that backward-incompatible interface changes > would jump to .2. and successive. > Maybe you followed our recent discussion about SONAME/SOVERSION in the ML, maybe not: what you suggest is exactly what we want to happen. Summarizing the previous discussion, this is what you get with 0.10.0: libpodofo.so -> libpodofo.so.1 libpodofo.so.1 -> libpodofo.so.0.10.0 libpodofo.so.0.10.0# The actual library That is the result of setting CMake target property VERSION[1] to "0.10.0", similarly to what was done before in 0.9.x, and setting SOVERSION[2] to "1", in what is a semantical change compared to 0.9.x (before it was matching the VERSION property). We'll make sure the SOVERSION property is incremented each time the ABI breaks. Regards, Francesco [1] https://cmake.org/cmake/help/latest/prop_tgt/VERSION.html [2] https://cmake.org/cmake/help/latest/prop_tgt/SOVERSION.html ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo 0.10.0 released
On Sun, 26 Mar 2023 at 18:39, zyx wrote: > It sounds like a good candidate for the Google Summer of Code, maybe? > Would such task be attractive enough? Anyway, we missed the deadlines for GSOC already[1], so we'll have to find another solution. Regards, Francesco [1] https://developers.google.com/open-source/gsoc/timeline ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] PoDoFo 0.10.0 released
Hello, I'm pleased to announce that PoDoFo 0.10.0 has been tagged for release after all the opened points were deemed closed. The lengthy changelog can be found in the github release page[1]. I wanted to to bring up some topics, some new and some already known: - I am very glad I received a lot of bug reportings from a few early adopters. A special thank to Igor Mironchik for many nasty bugs reported and Francesco Scalise for similar feedback as well; - The list of issues in Github is short and all of the currently reported issues are really request for enhancements. To be fully honest I never looked at the issues in the original SF project: I'll grab some help here and if you reproduce some older issue (and only in this case, since many may be fixed already) from the previous tracker please recreate a similar one in Github; - PoDoFo tools are still unsupported: while they compile successfully, with a few exceptions I never tested them. To save them from oblivion, I would really expect someone to adopt and re-test them, at least for a summer project. This work should also include removal of C style programming, and more common infrastructure (support protected pdfs everywhere, use of library parsing for arguments, Unicode arguments in Windows). This helps in making them more maintainable for the future and improves the code style to match what's in PoDoFo; - The API is not yet stable: I plan for further refinements before 1.0, see the TODO. Reviewing/modernizing a big object oriented library is a long process, especially if the language is C++; - Because of previous points I take no stance in recommending its packaging in Linux distributions (at least for now) to still give tools a chance. I would be happy to know PoDoFo 0.10 is packaged in other package managers (such as vcpkg, Conan, brew) but I also do not encourage the upgrade right now if they release tools as well and they can't decouple them, or they can't supply older PoDoFo versions as well; - The license is still LGPL2 as PoDoFo full re-licensing to dual MPL2+LGPL2 has **not** happened yet. I will focus on pursuing the topic in the next weeks. I hope next announcements will be shorter, first because I hope there will be less need for long introductions, secondly because it takes time to write them (a very long time in my case). I also have some ideas about a new simple static website where to publish announcements. I possibly have some people that can help me here to make it pretty, but if you want to beat the rush please write me privately. Forget about everything that is still not good and let's celebrate the first release following 0.9.x series. Thanks again Dominik for allowing this to happen. Cheers, Francesco [1] https://github.com/podofo/podofo/releases/0.10.0 ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo SO versioning
On Wed, 22 Mar 2023 at 21:24, Francesco Pretto wrote: > There will be the actual libpodofo.so.X and a single symlink > libpodofo.so pointing to that, which is what CMake seems to support > without much burden. @zyx, @Mattia I was actually wrong with this regard: when setting target property VERSION[1] together with SOVERSION[2], CMake will behave exactly as other build systems projects during install and produce the following files: libpodofo.so -> libpodofo.so.1 libpodofo.so.1 -> libpodofo.so.0.10.0 libpodofo.so.0.10.0# The actual library $ readelf -d libpodofo.so.0.10.0 | grep SONAME 0x000e (SONAME)Library soname: [libpodofo.so.1] So the full library versioning is preserved in the final library file, but it is not hard checked for linking, with the latter checking what specified by SONAME instead. I guess in the end this is what everyone wanted. So setting SOVERSION to a single number did the trick and everybody should be happy now. Sorry for the confusion and the wrong information reported. Cheers, Francesco [1] https://cmake.org/cmake/help/latest/prop_tgt/VERSION.html [2] https://cmake.org/cmake/help/latest/prop_tgt/SOVERSION.html ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo SO versioning
On Thu, 23 Mar 2023 at 14:33, zyx wrote: > That being said, count me as the third, whom is okay with the starting > point being .so.1. > Ok, good. Let's go for 1, then. Cheers, Francesco [1] https://github.com/podofo/podofo/commit/db491a6460b8087a30d1a834078ec85b373c7953 ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo SO versioning
On Wed, 22 Mar 2023 at 17:58, Michal Sudolsky wrote: >> I also suggest: >> - To arbitrarily start with SOVERSION "10" because it makes more clear >> that there were other incompatible ABIs before; > > Why not just use 1? Latest podofo is libpodofo.so.0.9.7 so why not restart > with libpodofo.so.1? > The rationale of "10" is really to point out it's not the first ABI that was produced. If you pick a single number and start from "1" there's nothing before other than "0". You are the second person (the first was Mattia) to prefer SOVERSION "1", so at this point I want to hear from zyx that, if I understood correctly, seems to care about packaging PoDoFo in RedHat based distributions. Regards, Francesco ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo SO versioning
On Wed, 22 Mar 2023 at 18:01, Michal Sudolsky wrote: > As Y and other parts are really irrelevant I think it is better to have just > libpodofo.so.X than to have both symlink libpodofo.so.X and actual > libpodofo.so.X.Y. > There will be the actual libpodofo.so.X and a single symlink libpodofo.so pointing to that, which is what CMake seems to support without much burden. ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo SO versioning
On Wed, 22 Mar 2023 at 06:19, zyx wrote: > > I still suggest to move to a single number SO versioning > > Okay, you convinced me. You've a "green" from my side for this change. > Good. Also doors will always be opened to move back to a "full" X.Y versioning later, if for example we find tools that update the version automatically (and we bend CMake to use only the major component X in SONAME), so I think there's no need to worry too much about this change now. Cheers, Francesco ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo SO versioning
On Tue, 21 Mar 2023 at 17:27, Michal Sudolsky wrote: > From what I know dynamic linker does not understand semver and it just > searches for equivalent names (probably both file name and soname). So in > this example you will probably also have symlink with version 1 and version > in soname set also to 1. And others will link to version 1 and not 1.11 or > 1.10 so both would potentially load with any SO user. > I think I clarified what it actually happens in my last message[1], and I also added few details on what CMake can and what can't do. > If something needs new functions from 1.11 but there is 1.10 in the system > it should probably be resolved/updated by the package manager? Yes, and the SONAME mechanism most often doesn't protect against mis-loading older library dependencies, as I learnt. Regards, Francesco [1] https://www.mail-archive.com/podofo-users@lists.sourceforge.net/msg04932.html ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo SO versioning
On Mon, 20 Mar 2023 at 12:45, Francesco Pretto wrote: > If there are two numbers, one specifying the ABI didn't > break, and the second with the additions, eg. 1.10, still any program > linking to a 2-number SO version 1.11 will refuse to load with 1.10, > even if it didn't use anything new introduced in 1.11, correct? I answered myself and the answer is: it depends on the SONAME attribute of the library being linked. That is: when you link a .so library, the end result binary may be linked to a completely different library than expected, or a missing one if SONAME misconfigured. I verified it myself empirically but it is also documented in this guide[1], which it may also be the document that zyx referred to: "The linker then reads the soname from the library file and records it into the application executable file. Finally, the linker creates the application so that it declares dependency on the library using the soname, not name or file name." The document also mentions what it may be a convention or "golden rule": "A library foo version X.Y is ABI-compatible with other versions with the same value of X in the version number. Minor changes preserving compatibility increase the number Y. Major changes that break compatibility increase the number X. [...] The Y component of the version number is not limited to just a single number." The fact is that the Y, or Y.Z component is not really reflected in the actual SONAME, see few examples in my system: $ readelf -d libjpeg.so.8.2.2 | grep SONAME 0x000e (SONAME) Library soname: [libjpeg.so.8] $ readelf -d libfreetype.so.6.18.1 | grep SONAME 0x000e (SONAME) Library soname: [libfreetype.so.6] $ readelf -d libavformat.so.58.76.100 | grep SONAME 0x000e (SONAME) Library soname: [libavformat.so.58] So linking these libraries will only bind to the ABI-breaking versioning (eg. libjpeg.so.8, not libjpeg.so.8.2.2), and the reference to the full versioning is erased in the linked binary (I verified it empirically with the command "strings"). I agree with Mattia here: having a SO version with the Y or Y.Z components seems to be cargo cult from (most) older projects, and the Y or Y.Z components for these projects are not be enforced by the SONAME mechanism, nor they are required. In fact a few notable examples that has actual libraries without Y.Z components at all exists: $ readelf -d libssl.so.3 | grep SONAME 0x000e (SONAME) Library soname: [libssl.so.3] # There are no libssl.so.3.Y nor libssl.so.3.Y.Z $ readelf -d libresolv.so.2 | grep SONAME 0x000e (SONAME) Library soname: [libresolv.so.2] # There are no libresolv.so.3.Y nor libresolv.so.3.Y.Z I think it's a sign of maturity questioning practices of the past and decide to do differently if it has some rationale. I still suggest to move to a single number SO versioning because: - It's one less burden to take care of when the non-breaking part of the versioning (which would be not checked anyway) should be updated; - I noticed CMake doesn't seems to support the full libtool machinery as pointed by Mattia, as setting SOVERSION[2] in the form X.Y will really end to set a SONAME like "libpodofo.so.X.Y", and not "libpodofo.so.X", which is what we actually want. I also suggest: - To arbitrarily start with SOVERSION "10" because it makes more clear that there were other incompatible ABIs before; - To preserve the libpodofo.so -> libpodofo.so.10 symlink (that is created by default with CMake) because it doesn't hurt and someone may want link pointing directly to libpodofo.so. If you want to comment further please do it quickly because the 0.10 release is imminent. Regards, Francesco [1] https://access.redhat.com/documentation/it-it/red_hat_enterprise_linux/7/html/developer_guide/creating-libraries-gcc#the_soname_mechanism [2] https://cmake.org/cmake/help/latest/prop_tgt/SOVERSION.html ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo 0.10.0-rc1
On Tue, 21 Mar 2023 at 21:21, Michal Sudolsky wrote: > So in future it will be removed and replaced by PODOFO_ENABLE_STATIC_TARGET > and PODOFO_ENABLE_SHARED_TARGET? What will it build if neither is set or both > are false? > Even if at some point it comes the ability to enable both targets I don't think we should remove anything because in some way we have to decide which target tests, tools and examples will use. I believe the feature should be seen as a commodity for the user using PoDoFo, and not something that forces us to duplicate every single target in the project. ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo 0.10.0-rc1
On Tue, 21 Mar 2023 at 17:02, Michal Sudolsky wrote: > So if I understand correctly these 3 variables will never be there at once? Not exactly. Based on feedback from xyz, I partially reverted the previous variables. We have now just a single PODOFO_BUILD_STATIC that will switch between a static build when true, and a shared one when false. PODOFO_BUILD_SHARED can't be set externally anymore (it's set internally only) and there's no dual target static/shared support just yet (it may be introduced in the future). The full list of supported CMake defines is here[1]. Regards, Francesco [1] https://github.com/podofo/podofo/#cmake-switches ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo SO versioning
On Mon, 20 Mar 2023 at 12:45, Francesco Pretto wrote: > still any program > linking to a 2-number SO version 1.11 will refuse to load with 1.10, > even if it didn't use anything new introduced in 1.11, correct? Hi Mattia, I answered myself and the answer is: it depends. I will write later tonight with my discoveries and a more substantiated proposal on what to do with SONAME handling. Regards, Francesco ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo SO versioning
On Mon, 20 Mar 2023 at 11:50, Mattia Rizzolo wrote: > Potentially, if you use more than one number (especially the 2-number > variant) you can use that to identify versions that added symbols > without removing something else, therefore the ABI was "increased" > without breaking. > But OTOH that just doesn't really work decently from a program > perspective... > > This is one thing that I would like to investigate if it can benefit or not really. If there are two numbers, one specifying the ABI didn't break, and the second with the additions, eg. 1.10, still any program linking to a 2-number SO version 1.11 will refuse to load with 1.10, even if it didn't use anything new introduced in 1.11, correct? ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo SO versioning
On Mon, 20 Mar 2023 at 07:55, zyx wrote: > My question is: why do you want to change it? What is that going to > fix? Is that just a personal reason? I'd rather stick with something > well-established [1], than changing such things only because I do not > like them. First: the major change is decoupling the two versions. That is, if we keep the x.y.z form, we could potentially have a 2.0.0 library version and still a 1.0.0 SO version. About moving to a single digit versioning it's not about personal preferences but removing decision points and a possible ambiguity: an ABI versioning should really state that the ABI broke compared to the previous version: with a x.y.z SO versioning we have similar form versions that are loosely related and can be possibly misunderstood. If we just state that the SO versions should match library version each time the ABI breaks, that removes the need for a decision but doesn't solve the ambiguity. If you think about introducing an automation, it's true that it may slightly easier to do (pseudocode): if (currentABIDump != previousABIDump) soVersion = libVersion; Than doing: if (currentABIDump != previousABIDump) soVersion++; Because the latter requires arithmetic, and the former doesn't. The latter becomes easier to do if the SO versioning is a single digit. Concluding, just looking at your example inspecting /usr/lib64, anything that can't be enforced is just a recommendation, not a rule: in my opinion, the libraries that use a single number for SO versioning better understood the point of such versioning. So I ask you: how comfortable you are with a SO version in the form x.y.z that doesn't match the library version anymore? I would love also to hear about from other users/packagers. > [1] Do you remember the SPDX license tags? It's better to use them [...] It's done. Regards, Francesco ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] PoDoFo SO versioning
Hello, It was reported that SO version changed at each release, which was not positive for Debian/Ubuntu. It has been like that since at least PoDoFO 0.8.0. I decided to decouple SO version from PoDoFo version, and decided to arbitrarily set[1] the SO version to 10, to start afresh with an easy versioning that should be incremented each time the library becomes ABI incompatible. I would really like to not have an ABI version in the form x.y.z. Any objection to this move? Any suggestion? It would be also great for the future to integrate some automation[2], to check for ABI changes against a previous version, and increment the SO version in the repository. I don't have time for this right now, but if you want to suggest some patches (also dealing with workflows in .github/workflows folder) to be integrated later you're welcome. Thank you, Francesco [1] https://github.com/podofo/podofo/blob/292c060fb563ce7c9e9ae99b2fefcdd39205e1a9/CMakeLists.txt#L25 [2] https://lvc.github.io/abi-compliance-checker/ ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo 0.10.0-rc1
On Mon, 13 Mar 2023 at 08:10, zyx wrote: > okay, so, there might or might not be two similarly named variables, > one PODOFO_STATIC and one PODOFO_BUILD_STATIC. [...] > A logical question: how does these two work with each other? The idea was to just let external user use be able to forcefully enable (but not disable) both static/shared targets. Anyway, that was just an hypothetical system: since we don't have it up and working, better not think about it too much. After reconstructing what I had in mind I can explain you better why I removed the _BUILD_ qualification: - In CMake I was trying to grasp both the meaning of build and use: for example, we build the static target and we use it in tests/examples/tools; - I also found some libraries actually that has a similar convention, for example I found libxml, openssl to be respectively configurable for building static library with CMake defines/env variables LIBXML_STATIC, OPENSSL_STATIC. Nevertheless, I think we can build a consistent naming also moving back to PODOFO_BUILD_STATIC, so I have just done it[1]: this should clear the topic. Consider I will still not propagate it to source defines: there I am splitting it in PODOFO_BUILD and PODOFO_STATIC/PODOFO_SHARED, so it's easier to control visibility attributes. I also added few other CMake switches[2], to aid packagers that may want to build the library and tools (at some point, if/when they are tested again), but not tests and examples. The plan is helping packagers of linux distro, and also Conan/brew/vcpkg as much as we can, so their life will be easier. Regards, Francesco [1] https://github.com/podofo/podofo/commit/292c060fb563ce7c9e9ae99b2fefcdd39205e1a9 [2] https://github.com/podofo/podofo/#cmake-switches ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo 0.10.0-rc1
On Fri, 10 Mar 2023 at 13:10, zyx wrote: > What I'm questioning is the variable name, the PODOFO_STATIC. Why would > not keep the PODOFO_BUILD_STATIC name for it? Is there any advantage > with it? The reason was to leave PODOFO_BUILD_STATIC and PODOFO_BUILD_SHARED free for potential future use case when we want to forcefully build both the static and shared targets (this is not supported today). If you are unconvinced with the current naming, try to immagine these variables by their semantical meaning: 1) Boolean to decide if building the default library target as static (TRUE) or shared (FALSE) and use it for tests/tools/examples. Today name: PODOFO_STATIC; 2) Proposed future boolean* to decide if forcefully build the static library target when set to TRUE. My proposal was to name this PODOFO_BUILD_STATIC; 3) Proposed future boolean* to decide if forcefully build the shared library target when set to TRUE. My proposal was to name this PODOFO_BUILD_SHARED. Another possible naming that would more backward compatible could be: 1) PODOFO_BUILD_STATIC; 2) PODOFO_ENABLE_STATIC_TARGET; 3) PODOFO_ENABLE_SHARED_TARGET. Even with this naming I would still drop support for PODOFO_BUILD_SHARED: please, one decision -> one variable, not two with complementary meaning. Let me know what you think about and/or add your proposal. (*) To be added later, maybe. On Fri, 10 Mar 2023 at 14:02, Raul Metsma wrote: > There is built in variable in cmake > BUILD_SHARED_LIBS — CMake 3.26.0-rc6 Documentation > cmake.org > I was aware of this variable, and I tried using it but the issue is that it doesn't grasp the fact that when unset or FALSE I would like the default to be shared. So I ended preferring a variable that when affirmatively set to TRUE it changes the default behavior, and avoiding the use of BUILD_SHARED_LIBS. ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo 0.10.0-rc1
On Fri, 10 Mar 2023 at 07:53, zyx wrote: > > On Thu, 2023-03-09 at 18:18 +0100, Francesco Pretto wrote: > I passed the parameters as: > -DPODOFO_BUILD_SHARED=OFF \ > -DPODOFO_BUILD_STATIC=ON \ > thus I did not want to build both targets. > > Does the rename make sense, I mean PODOFO_BUILD_STATIC to > PODOFO_STATIC? There were some ideas[1] to support dual static/shared targets that would be manually enabled and available in the build system by setting both PODOFO_BUILD_STATIC and PODOFO_BUILD_SHARED to TRUE. It can't be done easily right now because there is the new podofo_private target (which can be used by the library/tests/tools) that complicates stuff. I would let those variables free for now and have just a single switchable PODOFO_STATIC variable that decides if the whole build system (that includes also tests/tools/library) is using a statically compiled library when TRUE or a shared one when FALSE (the default). A symmetric PODOFO_SHARED cannot be set externally, which should make it less confusing. > The PODOFO_BUILD_LIB_ONLY is not called PODOFO_LIB_ONLY, > right? I mean PODOFO_BUILD_STATIC might fit better. Maybe. Maybe not. > There's no PODOFO_LIB_ONLY, not even in 0.9.x, so I don't know exactly what you mean. If PODOFO_BUILD_LIB_ONLY is confusing we can rename it to PODOFO_BUILD_LIBRARY_ONLY, which if enabled will skip building tests/tools/examples (was the same in 0.9.x). > Okay, makes sense to me. If they could be enabled in runtime, by some > switch or whatever, then it'll be a nice bonus. Otherwise those tests > were really slow and might not be part of a usual unit tests run, > because unit tests should be quick (at least from my point of view). > I think with catch2 it's possible to tag tests and control which tests to run with command line: https://github.com/catchorg/Catch2/blob/devel/docs/test-cases-and-sections.md https://github.com/catchorg/Catch2/blob/devel/docs/command-line.md#top It's not a priority for me. I will wait Mark or others to have a look and suggest something later. Regards, Francesco [1] https://github.com/podofo/podofo/issues/34#issuecomment-1407792409 > > Thanks and bye, > zyx > > > ___ > Podofo-users mailing list > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo 0.10.0-rc1
On Thu, 9 Mar 2023 at 08:33, zyx wrote: > Manually-specified variables were not used by the project: > > PODOFO_BUILD_SHARED > PODOFO_BUILD_STATIC > > I suppose these two had been renamed? > Yes, see the supported switches[1]. The compilation of both targets together is not currently supported, and if it worked before it was probably accidental[2]. > The tools are not part of the `all` target and `make help` doesn't show > anything similar to the tools, thus those are not build here at all. I > guess they should be part of the `all` target. > The tools are currently disabled. Read the relevant section[3] in the Readme. > The helloworld-base14 fails here with the following output: > I should have fixed it. Please retry with latest git, I haven't tested that helloworld for a long time. Symbol and ZapfDingbats will display something different than before because now I support the Unicode table for those fonts (most glyphs have now official Unicode codepoints), and latin code points will fail by design. > By the way, I found it weird to find the built helloworld files in the > `_build/target/` directory, but it is more like a habit to look for the > built files/binaries in the directory they are defined in (in this case > under `_build/examples/...`). I agree it makes sense to have the > executables beside the library they use, especially when the RPATH is > disabled. That's intended unless PODOFO_BUILD_LIB_ONLY is set to TRUE, and it makes the life easier in Windows builds. I added a message stating the output directory. > The trunk's unit tests contain some CVE-related tests. It makes the > test suite quite slow. I did not try to hunt the sources whether you've > them included or not, I'm sorry for being lazy, did you just drop those > tests or they need special invocation to be included in the list of the > unit tests, please? > The CVE-related tests are still there but I shortened them in TestMaxObjectCount using a smaller limit[4], and TestMaxObjectCount2 which should be the full test is disabled in regular runs. We should talk with Mark if that's enough and if everything is still working as it was before, because I have little expertise with that kind of issues. Regards, Francesco [1] https://github.com/podofo/podofo/#cmake-switches [2] https://github.com/podofo/podofo/issues/34#issuecomment-1407719557 [3] https://github.com/podofo/podofo/#podofo-tools [4] https://github.com/podofo/podofo/blob/master/test/unit/ParserTest.cpp#L94 ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] PoDoFo 0.10.0-rc1
Hello, I cleared the list of bug fixes, feature additions and API changes that I had in mind for 0.10, so I thought it was about time tagging a 0.10.0-rc1. In the past weeks I received quite some intense testing from some early adopter users, so I am very happy for the current solidity of PoDoFo. There were also very useful discussions about critical API changes that ended in PoDoFo, and those lead to make the API design even more robust, and code organization as well. After many delays I finally decided to move the I/O subsystem to a non PDF specific location (the "auxiliary"[1] folder, previously known as "common"). I also made a change that may be controversial, so I speak about it now: I renamed PdfRect to Rect and moved to "auxiliary". The rationale is the following: Matrix and Vector2 classes were added, Rect is coupled with Matrix (we can transform the rectangle with the matrix), and I found that either we prefix all the geometrical types with "Pdf", or we go without prefix for all of them. I found PdfMatrix and especially PdfVector2 non appealing (too long to type), so I decided to have all of them without Pdf prefix, because they are quite generic geometrical concepts that don't have a strong/unique coupling with the Pdf specification, except the fact that Matrix and Rect can be serialized through PdfArray (the conventions for the roto-translation matrix used in PDF are common also outside of PDF). Still the types are within the PoDoFo namespace, so we have now: - PoDoFo::Vector2 - PoDoFo::Matrix - PoDoFo::Rect which are all enough short to type. I am assuming the risk of clashes with other libraries low or avoidable qualifying the namespace/creating typedefs. If you don't like the naming of the classes, please suggest some alternatives, considering that all the three types are directly or indirectly coupled and should be grouped together. If no major discussion or bug fixing is required, I think we can have a 0.10.0 in a week/ten days: after that I will also be able to talk more about the experience of these two months after re-integration of pdfmm and the plans for the future. For Linux distribution packagers: I will recommend against 0.10 for packaging in Linux distros, for two reasons: tools are untested, and more API improvements are planned for 1.0. I will also talk more about this later. Cheers, Francesco [1] https://github.com/podofo/podofo/tree/master/src/podofo/auxiliary ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PdfPainter revamp
Hello zyx, some updates below. On Mon, 27 Feb 2023 at 10:16, Francesco Pretto wrote: > Then PdfPainter::GetContent() is fine. Done. > I will take inspiration from .net GraphicsPath.AddPath Done[1]. On Thu, 23 Feb 2023 at 14:02, Francesco Pretto wrote: > On Thu, 23 Feb 2023 at 08:32, zyx wrote: > > You changed it to `common`, `main`, > > `private`, `staging` and apart of `staging` > > I believe there's some more rationale for the separation I picked, I > explained everything in the SOURCE-LAYOUT.md document After some thoughts, I decided to rename "common" to "auxiliary" [2] and finished populating it with all the left files that were not prefixed "Pdf": a few actually existed in 0.9.x, but all of the ones that ended in this folder were created for 0.10 or renamed. While this endures on the categorization of the source files, it should be much more clear what ends in "main" and what should be put on "auxiliary", according to the definition in SOURCE_LAYOUT.md. There are some border line cases, but in the end the rule should be enforceable enough as I don't think much more should/will end in "auxiliary". Greetings, Francesco [1] https://github.com/podofo/podofo/blob/04206218e0bf2c6c750d55b0469d45c0fafe1650/src/podofo/main/PdfPainterPath.cpp#L79 [2] https://github.com/podofo/podofo/tree/master/src/podofo/auxiliary On Mon, 27 Feb 2023 at 10:16, Francesco Pretto wrote: > > On Mon, 27 Feb 2023 at 09:42, zyx wrote: > > I'd say the "String()" part of the function is kinda redundant, because > > the API shows it returns a string. Nonetheless, I've no strong opinion, > > the GetContentString() sounds good too. > > > > Then PdfPainter::GetContent() is fine. I'll go for it. > > > Thinking of > > it now, would it work to construct a path and apply it multiple times > > into the drawing context? > > PdfPainterPath is meant to be reusable of course. > > > I do not say to add a "copy from other Path" is a needed thing, it only > > felt like a good thing to me. > > I think it's a perfectly reasonable feature and easy to add. I will > take inspiration from .net GraphicsPath.AddPath[1]. > > Regards, > Francesco > > [1] > https://learn.microsoft.com/en-us/dotnet/api/system.drawing.drawing2d.graphicspath.addpath ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PdfPainter revamp
On Mon, 27 Feb 2023 at 09:42, zyx wrote: > I'd say the "String()" part of the function is kinda redundant, because > the API shows it returns a string. Nonetheless, I've no strong opinion, > the GetContentString() sounds good too. > Then PdfPainter::GetContent() is fine. I'll go for it. > Thinking of > it now, would it work to construct a path and apply it multiple times > into the drawing context? PdfPainterPath is meant to be reusable of course. > I do not say to add a "copy from other Path" is a needed thing, it only > felt like a good thing to me. I think it's a perfectly reasonable feature and easy to add. I will take inspiration from .net GraphicsPath.AddPath[1]. Regards, Francesco [1] https://learn.microsoft.com/en-us/dotnet/api/system.drawing.drawing2d.graphicspath.addpath ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Help wanted for 0.10: Restore PdfPainter::Arc() (and maintain SVG extensions)
I ended adding an implementation of DrawArc()/AddArc()[1], so the case is closed. Regards, Francesco [1] https://github.com/podofo/podofo/blob/b93b40feb52bfaf14d3680b1af5ccef66119a58d/src/podofo/private/PdfDrawingOperations.cpp#L80 On Sat, 4 Feb 2023 at 23:05, Francesco Pretto wrote: > I added a AddArcTo()[1] that is the equivalent of 'arct' postscript > operator[2] and the javascript arcTo()[3]. > ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PdfPainter revamp
On Fri, 24 Feb 2023 at 14:49, Francesco Pretto wrote: > We should try to release a 0.10 with a feature set that is in pair with... Correction: "on par with". ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PdfPainter revamp
On Thu, 23 Feb 2023 at 17:39, zyx wrote: > maybe Path::GetContent(), or Path::AsString()? As the GetString() feels > like there might be also SetString() Maybe PdfPainter/Path::GetContentString()? > (which it should, right? When one > wants to re-apply the path with this higher level API - the Path object > currently does not seem to be capable of "filling existing data" to it, > neither merge it with another Path object). I mean, the string is not > enough, if you cannot apply it anywhere - it would be nice to have a > higher level API for it. I think I can add a feature to add a path to another path. But creation from string would require parsing and validation to handle the current point, so I'm definitely not adding it now. We should try to release a 0.10 with a feature set that is in pair with what people would expect from 0.9.x to do reasonably good. All the rest is a missing feature and some loving care in form of PRs would be very welcome. > Yes, that's okay. I'm not sure we are on the same page. I meant > something like: [...] > just to re-use the Path class. You know, to limit different code paths. > It should be easier for testing too, and it might be a bit more > consistent, due to no shortcuts in the code, which is supposed to do > exactly the same thing as another part of the code. > Yes, we were talking about something different. Now I understand what you meant but in the way you suggest unnecessary buffer allocations and checks would be done. I agree with you that testing would be easier by reusing the existing path class inside PdfPainter, but I also think that PdfPainter and PdfPainterPath are coupled enough as it is now. We must be honest with ourselves and admit that PoDoFo was/is not super well unit tested, and that's not because it's intrinsically hard to test but because some of its devs (including/especially me) don't like/don't have much time to write tests, or have other unpublished test suites. I began to improve the current situation in PdfPainter but until one show up with a big amount of tests in a row I don't see it improving quickly. Cheers, Francesco ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PdfPainter revamp
On Thu, 23 Feb 2023 at 08:32, zyx wrote: > - The PdfPainterPath::GetView() sounds weird. When it comes to views, > then it's something like GUI-related for me. The Path has a > `content`, not a view. It returns a string_view, which is something > I do not know. The PdfStringStream has GetString(), not GetView(). > No big deal, I can rename GetView() to GetString(). In a sense I was thinking that one may not expect a PdfPainter class to have a GetString() method. But if also GetView() can be confusing, and we don't want to name it more specifically, we can be more conservative an have GetString() instead. > - When looking into (for example) DrawRectangle(), I expected to see > a use of a local `path` object, not to call drawing operations > indirectly - it feels like if you are going to change something, > you'll do it in two+ places (in the painter and in the path). > Actually this is something I really never pushed for. Before I had this PdfPainter::Path local object which was really a path being constructed (but not stroke/filled immediately). I ended removing that and introducing the external path construction with PdfPainterPath, so we didn't miss the ability to inspect it before pushing it to the painter, as you requested. PdfPainter::Draw... like functions will really do stroke/fill right after the call, so it doesn't mix well with the concept of "under construction". What I think you are suggesting here is more categorization: you may suggest to have a local object to just, for example, draw closed shapes (eg. a PdfPainter::Shapes). I think categorization may be interesting to consider but if you introduce it the consequence is that everything should obey to that concept, and we may come up a situation where it's hard to preserve. The only local "object" accessibility I introduced, and I think it's good to preserve, is PdfPainter::TextObject. This really helps separate those text functions that have similarities with path construction (MoveTo(), add text in current position...) from the other PdfPainter::Draw... like functions. In this way PdfPainter is really similar in working to an established API (the often mentioned .NET Graphics class), and without missing some of peculiarities of the PDF specification. In conclusion, I think the current design improved a lot after your early thoughts/comments. I also believe there's no need for further categorization. > You changed it to `common`, `main`, > `private`, `staging` and apart of `staging` being really confusing > name (does it have anything to do with "git staging"? I doubt it), > it makes it really hard to find the right place when searching > for the source files. I agree the previous source layout was confusing and also hardly enforceable. Yes, "podofo_private" was added, but it's privately used also by tests and tools, so we are not single target anymore. I believe there's some more rationale for the separation I picked, I explained everything in the SOURCE-LAYOUT.md document[1]. Note: "staging" should remind you of linux kernel staging folder. > - You should consider including podofo_config.h into each .cpp file > as the first include file, even when it looks like it's not needed > at the moment. The config file can contain switches for the other > include files, changing behavior for the compiler. Maybe in the > future, if not now. > I think at moment (and maybe in 0.9.x too) podofo_config.h[2] has not really any definition that is needed to be first in the compilation units. You may have noticed (or not) that all/most compilation units now have this include first: #include That's the header where one is supposed to put early defines for compilation units, if needed. > Again, these are only thoughts You're welcome. I think answering these and others help in better clarifying development choices, that may not be always obvious at first glance. Cheers, Francesco [1] https://github.com/podofo/podofo/blob/master/SOURCE-LAYOUT.md#source-directory [2] https://github.com/podofo/podofo/blob/master/src/podofo/podofo_config.h.in ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PdfPainter revamp
Hello zyx, PoDoFo devs,
an update on the PdfPainter situation: a rework of the PdfPainter has
been carried out to address some reviews/concerns. It follows the
changes and design notes:
- The previously described path "context" has been renamed/moved to a
PdfPainterPath[1] class, now representing an external path in
construction. The class allows to retrieve a string view of the path
currently being built, and can be drawn/clipped with
PdfPainter::DrawPath/ClipPath;
- A base "interface" like PdfContentStreamOperators[2] class has been
introduced offering a low level content stream manipulation layer to
be used by power users. PdfPainter implements all the methods of the
class privately: such low level functionalities can be retrieved by
casting the painter instance to PdfContentStreamOperators. It is worth
to add that such functionalities are still partially validated by the
internal state of the painter;
- PdfPainter and PdfPainterPath still offer an easy to use high level
interface for Pdf drawing operations, and now even more closely match
the API design of .NET Graphics and GraphicsPath class (to zyx for
reference: NET Graphics is really a MS official wrapper around HDC/GDI
Windows API);
- The text "context" has been renamed to PdfPainterTextObject, and the
PdfPainter::Text instance renamed to TextObject, to reflect the PDF
specification naming. This remains an interface to manually handle BT
.. ET stacking and add continuous text. The high level text API to draw
text remains PdfPainter::DrawText like functions.
I also privately received some feedback that relates to writing proper
glyph positioning: a status describing the painter being constructing
glyphs array ("[ gliphs1 delta glyps2 ... ] TJ") and glyph arrays writing
primitives were added. These should help in the future to the
introduction of text shaping with HarfBuzz[3].
It follows an example of use of the updated API:
PdfPainter painter;
painter.SetCanvas(page);
painter.TextState.SetFont(font, 15);
painter.DrawText("Test2", 100, 600, PdfDrawTextStyle::StrikeOut);
painter.TextObject.Begin();
painter.TextObject.MoveTo(100, 500);
painter.TextObject.AddText("Test");
painter.TextObject.End();
painter.GraphicsState.SetLineWidth(1);
PdfPainterPath path;
path.MoveTo(20, 20);
path.AddArcTo(150, 20, 150, 70, 50);
path.AddLineTo(150, 120);
painter.DrawPath(path, PdfPathDrawMode::Stroke);
path.Reset();
path.MoveTo(40, 40);
path.AddLineTo(100, 40);
path.AddLineTo(70, 80);
path.AddLineTo(40, 40);
path.AddCircle(200, 200, 60);
painter.DrawPath(path, PdfPathDrawMode::Fill);
painter.Save();
const double SquareSize = 6;
painter.GraphicsState.SetLineWidth(0.6);
painter.DrawRectangle(150 - SquareSize / 2, 70 - SquareSize / 2,
SquareSize, SquareSize);
painter.GraphicsState.SetLineWidth(0);
painter.DrawLine(150, 70 - SquareSize / 2, 150, 70 + SquareSize / 2);
painter.DrawLine(150 - SquareSize / 2, 70, 150 + SquareSize / 2, 70);
painter.Restore();
Here it follows an example of use of the low level interface:
auto& operators = static_cast(painter);
painter.TextObject.Begin();
painter.TextObject.MoveTo(100, 500);
// Some low level operations
operators.TJ_Operator_Begin();
operators.TJ_Operator_Glyphs("W", false);
operators.TJ_Operator_Delta(-500);
operators.TJ_Operator_Glyphs("orld", false);
operators.TJ_Operator_End();
painter.TextObject.End();
The goal of the PdfPainter revamp isn't being a 100% complete drawing
API, but put a more robust foundation for growing in the future
releases. If you have any further comment/review (can be as simple as
suggesting better names for classes/members), please don't be shy to
reply publicly: this makes the development process more transparent
and motivates me in replying. As soon as there are no concerns that
require immediate modifications, we can freeze the API and complete
few more bugfixes heading for a 0.10 release.
Cheers,
Francesco
[1]
https://github.com/podofo/podofo/blob/master/src/podofo/main/PdfPainterPath.h
[2]
https://github.com/podofo/podofo/blob/master/src/podofo/main/PdfContentStreamOperators.h
[3] https://github.com/harfbuzz/harfbuzz
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PdfPainter revamp
Hello zyx, my comments below. On Mon, 6 Feb 2023 at 09:18, zyx wrote: > From my point of view the "base" PdfPainter > should do just what the PDF standard drawing does, to expose all those > APIs in 1:1 manner. After that the "extensions" (or better a > PafPainter, which derives from the PdfPanterBase - or some better name) > can add wrapper functions, which will build on top of the base, adding > higher level API for common operations. It felt like your > PdfPainterExtensions aims to. First let's clarify what PdfPainterExtensions is right now: really it's a bunch of quarantined functions that were once in PdfPainter and needs to be cleaned/reviewed (if it will ever happen) before being reintegrated in PdfPainter once again. Secondly: somehow I am now feeling intrigued by your proposal that I translate to "Let's have a base class/interface of PdfPanter with just methods that match PDF operators 1:1". I think it could be a very interesting idea to have for power users, if we ensure the inherited PdfPainter will still be easy to user for most users and performing the same validations, and still have convenience methods like it has now (for example to draw circles/ellipses/etc). Let me work on it on a separate branch and show it to you what I have in mind. > That the wrappers/contexts need to access private members of the > PdfPainter makes me feel like not a great API design. The usefulness of the helper classes PdfPainterPathContext and PdfPainterTextContext is really just to conceptually separate these functions from the others in PdfPainter because they need a Beging()/End() semantics plus the other reasons I explained in my first email and the friendship is in fact used only to directly call private functions with same signature in PdfPainter through conveniently named public member instances painter.Path and painter.Text. If we agree that helpers class can be used to perform such conceptual separation, and we move to use them this way, I don't think we can come up with a design that's more friendly/convenient from the API user perspective. > I'd still reconsider whether the subobjects and all those "AddSometing()" > methods are needed (the 'Add' prefix of the functions feels unnecessary > and awful to me). I believe there must be a distinction between DrawSomething() functions that actually perform some stroking and/or filling and just adding to a path. If you noticed, DrawSomething() are just in PdfPainter and AddSomething() is just in PdfPainterPathContext. This is a similar approach from .NET Graphics[1] and GraphicsPath[2] (but the latter don't have "prolong to" stateful methods). I think you may want to imagine having no Draw/Add prefix at all or you imagine just the "Draw" prefix in PdfPainter and no prefix at all in PdfPainterPathContext. That would be more confusing to me. > I'm missing PdfPainter::/PdfPainterPathContext::getCurrentPath(), it's > needed for some drawing operators. Return it back, please. > First I explain why I removed it: I was trying to avoid double caching the raw string stream being built. So I ask you: - Why you need to access a raw string stream with just the content of the path? Consider that logically the paths may stack up, even if in the PDF content stream semantics maybe they don't do it really. This opens further questions that I don't really want to answer; - Later we may consider adding to the API logical paths, meaning a class PdfGraphicsPath that has similar methods to PdfPainterPathContext but logically contains the path being built and that can be re-used, for example with a function PdfPainter::DrawPath(path). In this sense it would be very similar to NET GraphicsPath class[2]. Would this fit better your use case? - For now, would direct access to the global string stream as a backdoor to be configured during PdfPainter construction (eg. "PdfPainter painter(stream);" be enough for you? I'm thinking adding it as well as discussed this issue[3]. Or access to the interface with all PDF operators as discussed above. > By the way, what is the reason to repeat in the class definition that > some code is "private:", while you already declared that the current > declaration section is "private:"? Similarly with the "public:" > section. Unneeded redundancy in the code, is it not? > It's a stylistic choice I invented to help me keeping disciplined and organized. Few examples I separate private functions that's called just inside the class and private functions that can be called outside by means of friendship, or default/deleted members or inline getters/setters. In general I like to keep a discipline in the code, but it must be lightweight, so of course it's redundant but I believe it's not that terrible. That's the reason I use Hungarian notation like "m_" or "s_" prefixes for members or static variables but I don't like full Hungarian notation itself, which it's just too heavy/redundant. Cheers, Francesco [1]
[Podofo-users] PdfPainter revamp
Hello PoDoFo users and devs,
I've been quite busy rethinking the PdfPainter API in the last few
days. This is something I didn't really think about when I was working
on pdfmm, but I was feeling I would have needed at some point. The
upstream code has been like in a roller coaster (I am not proud of
this after the pdfmm reintegration) but the API should be quite in a
robust state now. First I would like to summarize why I thought the
painting API needed intervention. PdfPainter:
- contained a mix of stateless "draw at" and stateful "prolong to"
path constructing operations, without a consistent, easily recognizable
naming scheme;
- has some methods that were stroking and some that were not, with no
clear reason of the difference;
- contained a obscure internal state that included the last point and
other tracking coordinates that were relevant only for few SVG
emulation methods. This state was also poorly maintained in these SVG
emulation functions as well;
- provided no validation at all of the issued functions.
Designing a painting API really requires thinking that all these
functions will be called unpredictability and with lot of
misunderstandings (the same happened/is happening for me as well).
Best idea would be getting as much inspiration from existing API
designs but I also noticed the PDF standard has some uniqueness:
- The top level content stream is not a path itself and no operator
will implicitly open a sub-path (this is different for example from
CanvasRenderingContext2D[1]);
- The text operators need to be within text objects (the paired BT ... ET).
This led me to think that is better to separate path/continous text
operations from the user friendly API in PdfPainter. The new
PdfPainter API:
- Is inspired by both javascript CanvasRenderingContext2D[1] (which is
clearly derived from PostScript) and .NET Graphics class[2], with a
lot of "draw at" oriented API and many user friendly shape drawing
methods;
- Provides a very bold separations of contexts where one can use path
or continuous text operations, by the use of two context class
instances which can always be accessed as public members
PdfPainter::Path and PdfPainter::Text. In the end these two context
classes just pass-through all the control to PdfPainter, but this
separation allows to better grasp the API and PDF specificity;
- Provides validation of the method calling sequence (e.g. no text
operators while out of BT ET or path operators without a path being
opened);
- Provides an inspectable graphics/text state that now also include
the dynamically build last position of the pen. The current
graphics/text can be accessed for read and edit with respectively
public members PdfPainter::GraphicsState and PdfPainter::TextState.
Here is a short example of use:
PdfPainter painter;
painter.SetCanvas(page);
painter.TextState.SetFont(font, 15);
painter.Text.Begin();
painter.Text.MoveTo(100, 500);
painter.Text.AddText("Test");
painter.Text.End();
painter.DrawText("Test2", 100, 600, PdfDrawTextStyle::StrikeOut);
painter.GraphicsState.SetLineWidth(1);
painter.Path.Begin(20, 20);
painter.Path.AddArcTo(150, 20, 150, 70, 50);
painter.Path.AddLineTo(150, 120);
painter.Path.Draw(PdfPathDrawMode::Stroke);
painter.Path.Begin(40, 40);
painter.Path.AddLineTo(100, 40);
painter.Path.AddLineTo(70, 80);
painter.Path.AddLineTo(40, 40);
painter.Path.AddCircle(200, 200, 60);
painter.Path.Draw(PdfPathDrawMode::Fill);
painter.Save();
const double SquareSize = 6;
painter.GraphicsState.SetLineWidth(0.6);
painter.DrawRectangle(150 - SquareSize / 2, 70 - SquareSize / 2,
SquareSize, SquareSize);
painter.GraphicsState.SetLineWidth(0);
painter.DrawLine(150, 70 - SquareSize / 2, 150, 70 + SquareSize / 2);
painter.DrawLine(150 - SquareSize / 2, 70, 150 + SquareSize / 2, 70);
painter.Restore();
We'll see with time if the validation is too much severe or we should
relax it in some parts. Also we could introduce a fail-safe mode in
the painter would allow for pass-through functionalities (still not
there). Still, the default should be to help users of the API to
produce clean streams.
There are some known bugs left:
- All the draw text multiline functions are still broken, at the
moment. Will be fixed before 0.10;
- I added an AddArcTo() path like method but still missing is
AddArc(x, y, radius, startAngle, endAngle, counterclockwise);
- The update of the last point when closing the path with "h" operator
is not done.
There are certainly tons of other unknown bugs and missing features.
Some more unit testing is introduced but we are not there yet.
Feedback and patches welcome, especially if you get idea of what the
new API is aiming to with these changes.
Cheers,
Francesco
[1] https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D
[2] https://learn.microsoft.com/en-us/dotnet/api/system.drawing.graphics
Re: [Podofo-users] Help wanted for 0.10: Restore PdfPainter::Arc() (and maintain SVG extensions)
On Tue, 24 Jan 2023 at 01:30, Francesco Pretto wrote: > the request here is if someone would take the responsibility to restore the > disabled method PdfPainter::Arc() [2], without making use of previous > I added a AddArcTo()[1] that is the equivalent of 'arct' postscript operator[2] and the javascript arcTo()[3]. Still missing AddArc() that is the equivalent of 'arc'[4] postscript operator and javascript arc()[5]. There's also a similar but different arc function that is part of SVG[6] which was previously implemented/emulated but it's now moved to unsupported helper class. I'm updating about other PdfPainter changes shortly. Greetings, Francesco [1] https://github.com/podofo/podofo/blob/f2b8abec1b3107e200215372a2cdb307ec96366d/src/podofo/main/PdfPainter.cpp#L1493 [2] https://hepunx.rl.ac.uk/~adye/psdocs/ref/PSL2a.html#arct [3] https://www.w3.org/2015/04/2dcontext-lc-sample.html#dom-context-2d-arcto [4] https://hepunx.rl.ac.uk/~adye/psdocs/ref/PSL2a.html#arc [5] https://www.w3.org/2015/04/2dcontext-lc-sample.html#dom-context-2d-arc [6] https://www.w3.org/TR/SVG/paths.html#PathDataEllipticalArcCommands ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Help wanted for 0.10: Restore PdfPainter::Arc() (and maintain SVG extensions)
On Tue, 24 Jan 2023 at 13:49, zyx wrote: > I expected, that the "inspectable PDF state stack in > PdfPainter" also covers the current position of the "pen" in the > current path. As it does not, my initial concern is void. > Yes, correct. All basic functions didn't have a "cursor" or "pen" position, as found in the 0.9.x code, so this makes a lot of confusion about the inner working of the "advanced" ones that I moved to the helper class. I think that's is better to have no "pen" position at all that have it somehow working for some functions only. It would definitely be a good improvement to introduce it in all functions in a clean way: with the automatic state stack as it is now it would also work with PdfPainter::Save() and PdfPainter::Restore(), it's just a matter of adding new fields to PdfPainterState[1] and maintaining them. That requires some time investment and mathematical rigour, both of them I can't provide right now. I will wait for a volunteer for that, and if nobody comes at least I will offer a replacement for the PdfPainter::Arc() function, as asked in the original message. Regards, Francesco [1] https://github.com/podofo/podofo/blob/e92ff22ccf5a315e5dd863fa495fc96d3166edce/src/podofo/main/PdfPainter.h#L57 ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Help wanted for 0.10: Restore PdfPainter::Arc() (and maintain SVG extensions)
On Tue, 24 Jan 2023 at 08:18, zyx wrote: > what precise SVG extension method you've on mind, please? I read Christopher Creutzig comment and there was a misunderstanding so I also answer you to explain that with SVG "extensions" I didn't mean something like SVG operators that ends in the PDF content stream. I meant macro/composed functionalities that can achieved only by composing several PDF operators. In the header documentation of those functions I enlisted they are described as the equivalent of some SVG operators which for sure need an internal state to be maintained for their correct working. The concerns I expressed are mostly related to unclear/fragile/possibly unreliable maintaining of such internal state. ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Help wanted for 0.10: Restore PdfPainter::Arc() (and maintain SVG extensions)
On Tue, 24 Jan 2023 at 11:51, Christopher Creutzig wrote: > I had a brief look at the 0.9.x implementation of ArcTo and was unable to > spot anything that goes beyond vanilla PDF. > Also, to clarify: I do understand that these methods produce correct PDF operators. That's not what I meant describing them as "extensions". With "extensions" I mean that they supply a composed/advanced functionality, which is not described by any single PDF operator. As such, other less controversial "extensions" methods are going to stay in the supported PdfPainter API, but not these because of the reasons I explained. I hope it is more clear now. ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Help wanted for 0.10: Restore PdfPainter::Arc() (and maintain SVG extensions)
On Tue, 24 Jan 2023 at 11:51, Christopher Creutzig wrote: > > HorizontalLineTo > > VerticalLineTo > > SmoothCurveTo > > QuadCurveTo > > SmoothQuadCurveTo > > ArcTo > > I’m still not sure I understand which SVG extensions you mean. Are you > talking about these functions mimicking operations that are found in SVG (and > a lot of other graphics contexts), or are you talking about something in the > PDF they generate? > Those functions were explicitly documented as such in the header, compare 0.9.x code[1]. For example: /** Append a smooth quadratic bezier curve to the current path * Matches the SVG 'T' operator. // ... */ void SmoothQuadCurveTo( double dX3, double dY3 ); There's no such 'T' operator in PDF. Anyway, I'm not demoting them because they are extensions, as they may be quality functions. I'm demoting them because of what I replied to zyx, which is mostly related to the internal state they depend on, which doesn't cope well with all the other "basic" functions. Regards, Francesco [1] https://github.com/podofo/podofo/blob/0.9.x/src/podofo/doc/PdfPainter.h#L595 ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Help wanted for 0.10: Restore PdfPainter::Arc() (and maintain SVG extensions)
On Tue, 24 Jan 2023 at 08:18, zyx wrote: > what precise SVG extension method you've on mind, please? The > CubicBezierTo() uses a PDF `c` drawing operator, which is a standard > thing, it's nothing like SVG extension. The PDF standard does mention > SVG, but on very different places, and only sparingly. > Sorry, I forgot to enlist the pre-existing extensions function I moved to PdfPainterExtensions: HorizontalLineTo VerticalLineTo SmoothCurveTo QuadCurveTo SmoothQuadCurveTo ArcTo > For > example, the PdfPainterExtensions::HorizontalLineTo() should use the > position from the PdfPainter::MoveTo(), or the end of the > PdfPainter::LineTo(), simply the current position for the path, not the > last position being set by the other PdfPainterExtensions() functions, > right? Wait a minute: I just moved the above functions as they were in 0.9.x to PdfPainterExtensions verbatim[1]. Any comment on their functioning applies to current 0.9.x stable code. > Similarly the other PdfPainterExtensions functions change the > current position in the PDF's drawing context, but not for the > PdfPainter itself, which can cause trouble in some cases. > PdfPainter never had a supported state with current position, compare 0.9.x[2]: LineTo() doesn't update a cursor at all. I'm still not introducing it in the reviewed code, since of course it's hard to maintain. I ask you to better understand why I decided to move such functions to an helper class. 1) The mutable state member variables which they are based are poorly documented/named, compare 0.9.x code[3]; 2) It's not immediately clear from the code how calling these functions interleaved with other simpler calls will behave, for example the above mentioned LineTo; 3) Maybe this is just a lack of comprehension but why HorizontalLineTo/VerticalLineTo both uses mutable state variables and don't update any variable after use? 4) We have now an inspectable PDF state stack in PdfPainter[5]. State of such extensions functions should be included in such painter state, but I have no idea how to do it because of the above questions; 5) The functions are not unit tested. The plan is to begin doing some unit testing, starting from core drawing functions which are more understandable as it is now. Until all these questions are answered, I think it's best that these functions are demoted (-> moved to helper class) as a precaution. If someone raise an hand an will take responsibility to address these concerns, for example the original author, I will be happy to welcome them back to the main supported API. > might some decisions be made in public, not to be just a single person > decision? I'm exposing/describing what I'm doing, asking for feedback and help. I'm sweeping vigorously on PoDoFo's code, and a lot of dust is expected to raise from ground. This is the moment for you and others to have a second and third thought on this work. Please realize that some of the comments you will also apply to 0.9.x code as well. Cheers, Francesco [1] https://github.com/podofo/podofo/blob/5723d09bbab68340a3a32923d90910c3d6912cdd/src/podofo/doc/PdfPainter.h#L595 [2] https://github.com/podofo/podofo/blob/5723d09bbab68340a3a32923d90910c3d6912cdd/src/podofo/doc/PdfPainter.cpp#L1365 [3] https://github.com/podofo/podofo/blob/5723d09bbab68340a3a32923d90910c3d6912cdd/src/podofo/doc/PdfPainter.h#L890 [4] https://github.com/podofo/podofo/blob/5723d09bbab68340a3a32923d90910c3d6912cdd/src/podofo/doc/PdfPainter.cpp#L1421 [5] https://github.com/podofo/podofo/blob/e92ff22ccf5a315e5dd863fa495fc96d3166edce/src/podofo/main/PdfPainter.h#L65 ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] Help wanted for 0.10: Restore PdfPainter::Arc() (and maintain SVG extensions)
Hello PoDoFo users and devs, aiming for a 0.10 release, which I would like to release soon, I recently fixed several bugs, most of them reported by Igor Mironchik, for which I'm personally thankful for. I also revisited PdfPainter and reworked it in a much more intense way, because it didn't receive the same love yet as other parts of the PoDoFo API: now PdfPainter has better method names, an inspectable PDF state stack, and better draw operations validation. During the review, I noticed there were several draw extension methods, that mocked SVG operators that are unavailable in PDF. These methods were implemented by adding some custom mutable state fields in PdfPainter (not very well named/documented, IMHO). Because of the adding of commands validation and PDF state stack inspecting, I believe those extension methods are now inconsistent with the rest of the API, and their usage in conjunction with other methods makes the behavior of PdfPainter unpredictable. Also, like most of the API in PdfPainter, also these extension methods were not unit tested. Hence, I decide to "demote" them to the staging[1] area of the source tree, until we understand better who could maintain them, and if they are really worth being in the main API. Since also the common method Arc() was also implemented with such extensions (but with an API accepting degrees and not radians for angles, which I believe is not mathematically rigorous for a drawing API), the request here is if someone would take the responsibility to restore the disabled method PdfPainter::Arc() [2], without making use of previous SVG extension methods, with the option to also maintaining/retest the new PdfPainterExtensions[3] class. If nobody helps, I will end doing it (at least restore PdfPatiner::Arc), but this will delay 0.10 release a bit because I'm exhausted right now. Let me know if you can volunteer on this. Cheers, Francesco [1] https://github.com/podofo/podofo/blob/master/SOURCE-LAYOUT.md#source-directory [2] https://github.com/podofo/podofo/blob/e92ff22ccf5a315e5dd863fa495fc96d3166edce/src/podofo/main/PdfPainter.cpp#L411 [3] https://github.com/podofo/podofo/blob/master/src/podofo/staging/PdfPainterExtensions.h ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Help wanted: libidn stringprep replacement
On Mon, 23 Jan 2023 at 08:33, zyx wrote: > PoDoFo is an Open Source project and will stay that way Sure thing, and not only: it will stay copyleft dual licensed LGPL2+/MPL2. > If you mean that the closed source forks of it with internal modifications > would have a complication and that makes you feel the LGPL dependency > would be a problem for such companies, As I stated previously, the only real issue with LGPL for honest/good willing companies is static linking. Consider companies that consciously want violate the LGPL requirements can do it today, they don't have to wait us to complete the dual licensing. > I agree with this, especially if it'll mean to have one less dependency > (I do not recall for what all the libidn is used in the PoDoFo, I'm > only lurking on the mailing list for the many past months). Libidn is just used for that "stringprep" function, which is a requirement for PDF encryption. > I'm sorry, I feel dumb, I do not follow. [...] > I agree it's a good thing to allow users build the project against a > distro-provided software/packages [...] Me neither I I could understand this one/follow you :) . If you have any doubt please write me personally or ask me informally on gitter[1]. Regards, Francesco [1] https://gitter.im/podofo/community ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Help wanted: libidn stringprep replacement
I insisted a lot on the benefits of being copyleft without being subjected to source/object code disclosure. In general the purpose is making PoDoFo more business friendly and fight for still being relevant. Ty to search google for "podofo" and look at first page of results: it's depressing. About libidn, there are specific multiple reasons to move away from it: - The LGPL license still doesn't allow a fully integrated static PoDoFo (once it will be MPL2) to not being subjected to LGPL requirements; - PoDoFo requires libidn 1.x, and can't upgrade to 2.x because the latter explicitly doesn't have stringprep (which is somehow an outdated protocol, for what I understood); - Libidn 1.x has an outdated build system which makes it harder to compiler under Windows; - Some package managers doesn't have libidn 1.x; - OpenSSL is now a requirement of PoDoFo: It would be way better if PoDoFo just supported AES3 without supplying an additional dependency. I hope to have been convincing enough. Regards, Francesco On Sun, 22 Jan 2023 at 11:43, zyx wrote: > On Sat, 2023-01-21 at 11:24 +0100, Francesco Pretto wrote: > > There are also licensing problems with libidn being only LGPL, and we > > are trying to get away from LGPL only. > > Hi, > as far as I know, LGPL can be used also for commercial or closed > sources projects. Why would there be any licensing problem when linking > against any LGPL library in the PoDoFo? Not talking that libidn is an > optional dependency. > Bye, > zyx > > > ___ > Podofo-users mailing list > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users > ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Build conflict between freetype, zlib and podofo
It seems your freetype build ended exporting zlib functions too, but it's just a wild guess. I don't know exactly which version of PoDoFo your are trying to run (I guess 0.9.x), but I would like to state here that I think for 0.10 we should transition PoDoFo to a library where only package managers (such as vcpkg on Windows, brew on mac, apt-get/rpm on linux, see the Readme[1]) or the playground[1] are encouraged and supported in the ML. Manually building dependencies (also in mobile platforms) is done on the user own responsibility, and it should be expected she/him to know how to deal with such issues. Regards, Francesco [1] https://github.com/podofo/podofo/#development-quickstart [2] https://github.com/podofo/podofo/tree/master/playground On Fri, 20 Jan 2023 at 23:43, Brian Erickson wrote: > Hello, > > I'm getting the following errors: > 1>freetype.lib(ftgzip.obj) : error LNK2005: inflate already defined in > zlibwapi.lib(zlibwapi.dll) > 1>freetype.lib(ftgzip.obj) : error LNK2005: inflateEnd already defined in > zlibwapi.lib(zlibwapi.dll) > 1>freetype.lib(ftgzip.obj) : error LNK2005: inflateInit_ already defined > in zlibwapi.lib(zlibwapi.dll) > If I use /NODEFAULTLIB, I get multiple "error LNK2001: unresolved > external symbol "void __cdecl operator delete(void *,unsigned __int64)" > (??3@YAXPEAX_K@Z)". > > There seems to be conflict between freetype.lib's gzip and podofo.lib's > zlib. > I am using Visual Studio 2019 on Windows 8. > Is there some option, I'm missing? > > Brian > ___ > Podofo-users mailing list > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users > ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] Help wanted: libidn stringprep replacement
Hello PoDoFo users/devs, there are juicy news coming for PoDoFo soon, but with this message I am here to ask for some help, and prepare also for some other similar requests later. I would like to evaluate compiling PoDoFo with vcpkg[1] in Windows, but I'm noticing libidn is not available at the version we need (we need 1.x, they have only 2.x). There are also licensing problems with libidn being only LGPL, and we are trying to get away from LGPL only. So, in few words, who would like to write a replacement for the stringprep[2] function which is used for PDF encryption? There's a Rust implementation which is really small (lot of code is just static character tables) and has a MIT license, so we could just port the code to C++ and release on the same license without legal issues. Alternatively we could try to grab the code from ICU[2], but I don't know their license/where is the code. Anyone interested? Cheers, Francesco [1] https://vcpkg.io/en/index.html [2] https://unicode-org.github.io/icu/userguide/strings/stringprep.html [3] https://github.com/sfackler/rust-stringprep ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Documentation error
I fixed it in master (0.10-dev). Also consider that coordinates passed may be influenced by CTM (current translation matrix). Cheers, Francesco On Wed, 18 Jan 2023 at 02:27, Brian Erickson wrote: > Hello, > > Regarding: In the file PdfPainter.h, around the functions "DrawImage". >both of the functions. (See Below my message) > The phrase "bottom left position" makes no sense > for single numerical value. Shouldn't it be just "left position"? > > ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo-next pushed to master
I already have a small update: PoDoFo is now fully OpenSSL 3.0 compatible[1], and the code is backward compatible with OpenSSL 1.1. I created a gitter community[1] and I invited some of you: feel free to join to have some informal asynchronous chatter there. This will probably replace the PoDoFo discord channel. Greetings, Francesco [1] https://github.com/podofo/podofo/commit/55c2ffd53b9eff2ac0418b3bce1a29e9a6688359 [2] https://gitter.im/podofo/community# ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] PoDoFo-next pushed to master
Hello PoDoFo developers, users, as previously anticipated, PoDoFo-next (the PoDoFo API rework based on pdfmm) has now been pushed to the project repository, effectively becoming the new PoDoFo's codebase (a PoDoFo 0.9.x branch has also been created). Because of this pdfmm is effectively terminated and its repository has been archived. I discussed several times the objectives that were pursued when working with PoDoFo's code, so I will try to highlight other stuff this time. There's a changelog[1] of new features, reworks, and bug fixes recently introduced. A 0.10 release could be tagged to mark the current progress, but I'll wait few days if it arrives some quick feedback with urgent bugs. There's also a long TODO[2] list which I would like to clear before having a 1.0 release. There a couple of things that were added recently that I believe are very interesting: 1) I imported some code from pdfium[3] to decode /CCITTFaxDecode filter. Some more code could be imported in similar way for other stuff that require a lot of research; 2) I imported chromium numerics[4] which was used by pdium. This allows for much better overflow checks. This may be of special interest for Mark... There are also 3 things I'm not entirely happy about the current state of PoDoFo-next: 1) PoDoFo-next is not yet a full replacement for PoDoFo, mostly because of tools. As anticipated I just did a mechanical port of tools (this porting operation actually helped improving the API), but they are completely untested and I am not interested in maintaining them, except for a couple (podofosign and podofotextextract). In general I would like tools to be same quality as the library code (it is currently not, in my opinion: too much C style programming left), and have a shared framework with common utilities for parsing of commands, handle of crashes, handle Unicode strings on Windows, etc. If there's an interest in continuing the software distribution in linux distros this should be fixed; 2) A large part of the API is not tested publicly. This is bad; 3) The procedure to sign PDF documents has changed a lot, but there's no publicly available test/example available and podofosign is untested as well. Also still there's no high level signing API yet: this may come later, maybe after 1.0. Also: - I'm sorry because I covered the recent README markdown conversion. Some chapters may be re-integrated later; - Some other things I regressed may required fixes from specialized people (I will specify it later); - I am sorry if I don't answer too much in the ML, especially for topics where I have a direct experience and I could have one thing or two to say. I will try improve this. So far I didn't measure strong interest for pdfmm/PoDoFo-next but this also had advantages: I could work for long time with no disturb. I think this may change a bit with the upload to the official PoDoFo's repository. Because this is a complex project and working on it takes a lot of time, every help is welcome (also in reviewing PRs) and if you have some big work in mind let's talk about it in the ML a bit. I would be glad if the website is revamped, but I have no passion for that. As a last message I would say that I'm personally very proud of this milestone, even if I'm a bit sad that some stuff took way too much than I imagined: while modern C++ can be cool, some peculiarities of the language still make it very slow do design high quality interfaces/utilities. With the work in pdfmm/PoDoFo I could close the circle on stuff I never sorted out with C++, which is great, but achieving all of this had a very big cost in terms of energy and weekends spent on the project. Greetings, Francesco [1] https://github.com/podofo/podofo/blob/master/CHANGELOG.md [2] https://github.com/podofo/podofo/blob/master/TODO.md [3] https://pdfium.googlesource.com/pdfium/ [4] https://chromium.googlesource.com/chromium/src/base/+/master/numerics/ ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Dual Licensing
On Fri, 9 Dec 2022 at 10:21, Dominik Seichter via Podofo-users wrote: > The re-license will happen gradually with files being modified their > licensing headers incrementally. > The process has begun in pdfmm with all the new files that I wholly authored were dual licensed LGPL2+/MPL2[1], making them compatible again with PoDoFo license and allowing the merge that will happen soon. > Starting from now we will also require new contributions to be dual licensed. > A github pull request template has been added[2] to the github repository reflecting this requirement. Greetings, Francesco [1] https://github.com/pdfmm/pdfmm/commit/f6280a136e31ae1347e1387698606cb0910256f5 [2] https://github.com/podofo/podofo/blob/master/.github/pull_request_template.md ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo-next status update
A small news after the latest status update: - merge PoDoFo latest patches into pdfmm: DONE [1]. pdfmm is now on par with PoDoFo latest fixes and features. You know pdfmm is coming into PoDoFo github very soon once the mechanical port of PoDoFo tools is done, which should be the last long and boring task. Rename pdfmm to PoDoFo is boring as well, but should take around 3-4 hours. Greetings, Francesco [1] https://github.com/pdfmm/pdfmm/commits/master On Sat, 3 Dec 2022 at 11:20, Francesco Pretto wrote: > as promised in some places I am posting another status update for the > pdfmm/PoDoFo merge situation. > ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo-next status update
Hello, as promised in some places I am posting another status update for the pdfmm/PoDoFo merge situation. Short news: I finished all the big refactors/reviews that I wanted to hand over for pdfmm 0.10, that wants to become PoDoFo-next/PoDoFo 1.0. The ETA of the previous status update was missed because of a busy schedule on unrelated tasks and also lot of initially unintended features that were actually delivered to pdfmm, like better text extraction[1] or more PdfImage decoding options[2]. The last very big update that I delivered is the long promised PdfField/PdfAnnotation hierarchy/ownership refactor[3].Basically the main issues with PdfField/Annotation API were: - It wasn't always clear who was responsible to own the instances of these types, especially for PdfField instances; - It wasn't very handy to access these items collections, like the /Fields array in the /AcroForm, or the /Annots array in pages, or the field children list in /Kids array; - the hierarchies for both PdfField/PdfAnnotation were unclear and incomplete, and there wasn't a clear coupling between the two. All of this work can be visualized in the attached UML diagram with the new hierarchies. Deliver an API usability on pair with features of other modern languages is far to be easy in C++, showing several limits of the language or requiring features that are very hard to grasp for C++ developers (eg. creating custom iterators). Also the PDF specification is sometimes hard to model in a object oriented API. The plan now continues with the following tasks: - merge PoDoFo latest patches into pdfmm; - finish mechanical port of PoDoFo tools to pdfmm; - rename back pdfmm to PoDoFo; - create a PoDoFo-next branch in PoDoFo's github and upload all this work. More API changes are to be expected in the PoDoFo-next branch, before what should be 1.0, but I expect those to be not that big like the ones that happened in pdfmm repository. I consider it an imperative to create this PoDoFo-next branch and deliver all of this work under the PoDoFo name. My hope is to finish these tasks before the end of the year but I already know it will be hard: around 80% of the time of the last refactor was done on my free time, and probably the same will happen for the above tasks. Also, I am going to be father soon, so consider my attempts to deliver slowed down by family responsibilities in the future. I hope you appreciate this work and still hold on waiting it coming to PoDoFo github. Of course you can preview all the work on pdfmm repository[4], which I guarantee you is way more tested behind the scenes than what the public unit tests suggest, especially for the new features. Cheers, Francesco [1] https://github.com/pdfmm/pdfmm/commit/9229908cb89a7a62a697aed01be2c046f4154bd1 [2] https://github.com/pdfmm/pdfmm/commit/9d6fc3fca7a00217b8ee431aa831eab0fbf3b4fe [3] https://github.com/pdfmm/pdfmm/commit/05faca589b732cf0b78122dabfd4a39c285e9a2b [4] https://github.com/pdfmm/pdfmm ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Fails to build with gcc 12.2.1
Hello zyx,
if I am not confusing it for something else, it seems we actually received
a proper patch for this issue as a pull request[1] some time ago. I would
be glad to just merge it but at the moment it would be a blind merge on my
side. If you confirm it working I will just merge it, or ask Dominik for
repo permissions.
Cheers,
Francesco
[1] https://github.com/podofo/podofo/pull/5
On Tue, 29 Nov 2022 at 07:58, zyx wrote:
> Hi,
> while I've been replying to a private request derived from a public
> thread (who likes these?), I realized I cannot build PoDoFo at
> r2063 anymore, due to:
>
> In file included from /usr/include/cppunit/TestAssert.h:8,
> from /usr/include/cppunit/TestCase.h:6,
> from /usr/include/cppunit/TestCaller.h:5,
> from /usr/include/cppunit/extensions/HelperMacros.h:9,
> from .../podofo/trunk/test/unit/StringTest.h:24,
> from .../podofo/trunk/test/unit/StringTest.cpp:21:
> /usr/include/cppunit/tools/StringHelper.h: In instantiation of
> ‘typename std::enable_if<(! std::is_enum<_Tp>::value),
> std::__cxx11::basic_string >::type
> CppUnit::StringHelper::toString(const T&) [with T = PoDoFo::PdfString;
> typename std::enable_if<(! std::is_enum<_Tp>::value),
> std::__cxx11::basic_string >::type =
> std::__cxx11::basic_string]’:
> /usr/include/cppunit/TestAssert.h:74:50: required from ‘static
> std::string CppUnit::assertion_traits::toString(const T&) [with T =
> PoDoFo::PdfString; std::string = std::__cxx11::basic_string]’
> /usr/include/cppunit/TestAssert.h:168:58: required from ‘void
> CppUnit::assertEquals(const T&, const T&, SourceLine, const
> std::string&) [with T = PoDoFo::PdfString; std::string =
> std::__cxx11::basic_string]’
> .../podofo/trunk/test/unit/StringTest.cpp:182:5: required from here
> /usr/include/cppunit/tools/StringHelper.h:25:9: error: no match for
> ‘operator<<’ (operand types are ‘CppUnit::OStringStream’ {aka
> ‘std::__cxx11::basic_ostringstream’} and ‘const
> PoDoFo::PdfString’)
>25 | ost << x;
> | ^~~~
>
> It looks like there's missing some operator definition. I did not look
> any deeper on this. I'm not sure whether it would make any sense, if
> the pdfmm project is supposed to be merged back soon (I did not try to
> build that one).
> Bye,
> zyx
>
>
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users
>
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo-next status update
Hello, I wanted to post another quick status update regarding pdfmm/PoDoFo-next: the review is proceeding steadily, but at a slower space than initially thought because of very complex refactors that were performed. The last two classes that received attention were: - PdfObjectStream (was PdfStream): gained true streaming operations and better comprehensive accessibility methods. Contrary to its name, PdfObjectStream didn't provide streaming operations using the IO system, which was limiting. PdfObjectStream also now refuses to decode jpeg images, or any "media" filter: this was necessary because image decoding isn't an unambiguous operation (eg. it may require specifying the pixel format of the target). The main interface to decode media/image filters is now through PdfImage; - PdfImage: Now provides a DecodeTo(buffer, pixelFormat) method to decode images on the given buffer/stream specifying the pixel format. Now a couple of medium difficulty review tasks are left in my TODO lists. Then the plan is to finish port the tools, rename back pdfmm to PoDoFo and upload it in a PoDoFo-next branch in github. The E.T.A. is now late summer/end of September. I will inform you again when the last review tasks are done and "mechanical" tasks begin. Greetings. Francesco ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] podofo 0.9.8 fails with GCC 12
I can't directly help on the issue since I still don't have any gcc12 enabled system plus in pdfmm I abandoned cppunit in favor of catch[1] so I don't have to solve this issue for podofo-next. Anyway, looking at the error and where it happens in cppunit source[2] it seems now a string conversion to be provided overloading the operator<< to OStream for types used in CPPUNIT_ASSERT_EQUAL may be necessary. In this case the fix would be quite easy, and it can be fixed by adding the overload in PoDoFo unit tests extensions[4]. Are you sure the issue is actually caused by gcc12 upgrade and it's not actually caused by cppunit upgrade? Regards, Francesco [1] https://github.com/catchorg/Catch2 [2] https://cgit.freedesktop.org/libreoffice/cppunit/tree/include/cppunit/TestAssert.h#n168 [3] https://cgit.freedesktop.org/libreoffice/cppunit/tree/include/cppunit/portability/Stream.h#n82 [4] https://github.com/podofo/podofo/blob/master/test/unit/cppunitextensions.h On Mon, 25 Jul 2022 at 15:32, Mattia Rizzolo wrote: > Hi Wolfgang, > > On Sun, Jul 24, 2022 at 04:25:34PM +, Wolfgang Stoeggl via > Podofo-users wrote: > > this is the patch, which is currently used in Fedora [1]: > https://src.fedoraproject.org/rpms/podofo/raw/rawhide/f/podofo-gcc12.patch > > Thank you for the link. > > So, effectively fedora is just disabing the failing tests. > Indeed, I just received a proposed similar patch in Debian too: > https://salsa.debian.org/debian/libpodofo/-/merge_requests/2 > > > So nobody has actually investigated the failures and did a real fix? > > -- > regards, > Mattia Rizzolo > > GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. > More about me: https://mapreri.org : :' : > Launchpad user: https://launchpad.net/~mapreri `. `'` > Debian QA page: https://qa.debian.org/developer.php?login=mattia `- > ___ > Podofo-users mailing list > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users > ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] PoDoFo-next status update
Hello PoDoFo devs and users, I have a quick update on the pdfmm/PoDoFo-next merge status: - I checked in the text extraction API, with a small test[1]; - I checked in a full review/revamp of the IO subsystem. The latter review has been more complex than I initially thought, but eventually successful. Basically the aim for the IO system review was cleaning it and making it simpler and more powerful at the same time: one of the issues of the previous hierarchy was for example that PdfInputDevice and PdfOutputDevice weren't inheriting PdfInputStream and PdfOutputStream respectively, needing adapter classes to interchange instances. Also the naming choices were sometimes weak, as for example PdfOutputDevice had in fact a read-write contract. The new hierarchy inspires from C++, .NET hierarchies and tries to take the best from all worlds: non overlapping Read/Write contracts/interfaces exist but most implementers for these just inherits a merged Read/Write StreamDevice[2] class similar to the Stream class in .NET[3]. This is a major cleaning/simplification as it makes the hierarchy easier/more balanced, as there is no requirement to have specialized implementations for all the Read/Write/ReadWrite combinations, a lot of those were lacking previously making the API looking incomplete. This is trading a bit of type enforcement (which anyway wasn't fully enforced before) to have less implementations to maintain. Specialized Read/Write only implementations are still possible and few notable examples exist (eg. PdfCanvasInputDevice). Attached is the UML diagram of the new hierarchy: the naming choices has been very carefully weighted so that the name of the classes are not excessively long (the "Pdf" prefix only for these classes has been sacrificed, also because they are very generic use). Even thought I have quite some experience with big refactors, it's always surprising how long it takes to do accomplish those: I reached the current model after more than 8 iterations/reversals. With these news, my list of TODOs is shortening quickly[4]. A couple of medium API reviews plus the porting of the tools and I will be ready to integrate into PoDoFo-next. The plan is still this summer, hopefully before the end of August. Cheers, Francesco [1] https://github.com/pdfmm/pdfmm/blob/f2be85e365a186f51fd13147cc6a0f1bc6ce0aa6/test/unit/TextExtraction.cpp#L15 [2] https://github.com/pdfmm/pdfmm/blob/675c03a872c0d8969ae5e123940c88712107a03b/src/pdfmm/base/PdfStreamDevice.h#L27 [3] https://docs.microsoft.com/en-us/dotnet/api/system.io.stream?view=net-6.0 [4] https://github.com/pdfmm/pdfmm/blob/master/TODO.md ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] An error exists on this page...
Hello, you're right something is wrong with the text. In particular something is wrong with the embedding of the font: my advice is that you should really use subsetting with PdfFontCache::GetFontSubset() when retrieving the font, otherwise it will embed the whole font and that may cope with the encoding you picked, possibly causing the issues you're seeing. Subsetting forces PoDoFo to create a different font type (/Type0), which is a more modern font type and works better with fonts with Unicode character set (like the one you're using). Unfortunately there are some other bugs with subsetting TrueType fonts in PoDoFo 0.9.x series, but subsetting Arial usually works fine. I can't help more with PoDoFo but in a couple of months PoDoFo-next, which is the new code base for PoDoFo, will appear and that handles these scenarios better, it's easier to code and has a lot of bug fixing. Regards, Francesco On Mon, 13 Jun 2022 at 12:33, Blayne Cullen wrote: > > Hello PoDoFo Team, > > > > I have been using the product for a little over a year now and I have been > intermittently getting the Adobe Acrobat error: “An error exists on this > page. Acrobat may not display the page correctly. Please contact the person > who created the PDF document to correct the problem.” (Screenshot attached). > This error does not occur in all of our PDF productions, just a few. The > generated PDF appears to be correct and on opening of the file in other PDF > viewers, no error is mentioned (though this is probably because they don’t > have the same error checking features that acrobat have). Also attached is a > copy of a simple example PDF document that contains the error. Some debugging > points to the text or even the font as the culprit, but this could be a red > herring. > > > > I have recently upgraded PoDoFo and its dependencies in an effort to resolve > the problem, but no luck. > > We are currently using: > > Visual Studio 2022 > FreeType 2.12.1, Z-Lib 1.2.11, Jpeg 9d > Targeting Windows 10 > Using PoDoFo 0.9.8 - 32 and 64bit shared libraries (dll) > > > > Look forward to your reply, > > Thanks, > > Blayne > > ___ > Podofo-users mailing list > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo virtual meeting
Quick reminder: meeting in less than 30 minutes (10:00). https://meet.google.com/ewa-whdr-wsp See you there very soon ;-) . On Tue, 7 Jun 2022 at 11:54, Dominik Seichter wrote: > > Looking forward to meeting many of you tomorrow! > > Cheers, > Dominik > > On Tue, Jun 7, 2022 at 11:07 AM Francesco Pretto wrote: >> >> Hello, >> >> as promised here is the link to conference room that will be used for >> the meeting tomorrow morning Wednesday June 8th at 10am (UTC+2). >> >> https://meet.google.com/ewa-whdr-wsp >> >> It's the same link for the ones that already received the invite. I >> will connect tomorrow at around 9:45 and start accepting other people >> at that time. >> >> Cheers, >> Francesco >> ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo virtual meeting
Hello, as promised here is the link to conference room that will be used for the meeting tomorrow morning Wednesday June 8th at 10am (UTC+2). https://meet.google.com/ewa-whdr-wsp It's the same link for the ones that already received the invite. I will connect tomorrow at around 9:45 and start accepting other people at that time. Cheers, Francesco On Wed, 25 May 2022 at 23:20, Francesco Pretto wrote: > > As corrected by Dominik, the meeting is set on June 8th at 10am UTC+2. > I just sent the invites to maintainers and contributors that showed > interest in the previous polls. The meeting room link will be shared > publicly a couple of days before the event takes place. > > Cheers, > Francesco > ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo virtual meeting
As corrected by Dominik, the meeting is set on June 8th at 10am UTC+2. I just sent the invites to maintainers and contributors that showed interest in the previous polls. The meeting room link will be shared publicly a couple of days before the event takes place. Cheers, Francesco On Mon, 23 May 2022 at 14:23, Dominik Seichter wrote: > > Hi Francesco, Hi zxy, Hi Mabri, Hi PoDoFo developers, > > Francesco and I discussed it again and would like to hold the PoDoFo virtual > meeting now on June [8th] at 10am (UTC+2 Berlin/Rome/). Please block your > calendars accordingly - invitation links will be sent soon. I would be happy > if many of you could join and discuss the next steps. > Please reserve 90 minutes for the meeting - we expect to stay in this time > frame and do not need more of your precious time. > > The last planned agenda was: > - [15min] Quick introductions, description of PoDoFo usage; > - [10min] pdfmm improvements over PoDoFo, propose to merge back; > - [25min] PoDoFo relicensing to more permissive license: yes/no, which one; > - [25min] PoDoFo development model, responsibilities, git adoption. > > ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Future ABI stability of PoDoFo
Hello Mark, I repeat because at some point I introduced some element of confusion: for now the library will be compiled with enforced set(CMAKE_CXX_STANDARD 17) and the public API will use only C++17 types/functions. std::span and std::format usage, as it is now, will be hidden by use of fillers in different namespaces. As such, the PoDoFo headers/binaries themselves will be safe to use in a C++20 compiled project including/linking PoDoFo. In PoDoFo non header exposed code (compilation units only) I may take a little bit more freedom, like for example using some fillers to enlarge compiler support even for C++17 features that were added in very late compiler versions. For example floating point std::from_chars overloads[1] were added only in gcc11. The minimum requirements for PoDoFo-next compilation for the most popular compilers/toolchains should be: - gcc 8.1 - clang/llvm 7.0 - msvc++ 14.16 (VS 2017 15.9) Cheers, Francesco [1] https://en.cppreference.com/w/cpp/utility/from_chars On Tue, 10 May 2022 at 18:11, Mark Rogers wrote: > > Hi > > I don't think any of the main compilers have complete C++20 support yet, and > defects are still being found in the C++20 standard so it's not completely > stable: > > GCC partial C++20 support > https://gcc.gnu.org/projects/cxx-status.html#cxx20 > > Clang partial C++20 support > https://clang.llvm.org/cxx_status.html#cxx20 > > VC++ partial C++20 support > https://devblogs.microsoft.com/cppblog/msvc-cpp20-and-the-std-cpp20-switch/ > > Additionally some defects in the C++20 standard are still being discovered: > https://devblogs.microsoft.com/cppblog/msvc-cpp20-and-the-std-cpp20-switch/#iso-c20-continuing-work-defect-reports-and-clarifications > > It might be ok to use selected C++20 features, but how easy is it to identify > which parts of the C++20 standard are stable and are available across the > main compilers? > > Best Regards > Mark > > -- > Mark Rogers - mark.rog...@powermapper.com > PowerMapper Software Ltd - www.powermapper.com > Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL > > > > On 05/05/2022, 08:43, "Francesco Pretto" wrote: > > Hi Christopher, > > On Thu, 5 May 2022 at 08:16, Christopher Creutzig > wrote: > > > > Backporting required parts of std::span and having a layer that > switches between std::format and fmtlib shouldn’t be too hard, assuming these > are only used internally and nothing in the API expects span inputs, for > example. But would we require contributors to use a C++20 enabled compiler? > > > > > > Please note that what you suggest it's already in place in pdfmm: I > use fmtlib in place of std::format and a backported std::span. > > Thinking a little bit more about the topic, let's not argue too much > about this: for the API/ABI surface I will just stick to C++17 > requirement and hide the fact I'm using std::format and std::span. > > Cheers, > Francesco > > > ___ > Podofo-users mailing list > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users > ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Future ABI stability of PoDoFo
My tentative plan: - Do the meeting, know each other, discuss important stuff :-) - (pdfmm-repo) Finish "mechanical" port of tools to pdfmm. As said previously I will do the port but other people should ensure the tools still work as expected; - (pdfmm-repo) Finish API review, check-in text extraction API, create a pdfmm 0.10[1]; - (pdfmm-repo) Rename back references from pdfmm -> PoDoFo; - (pdfmm-repo) Change license of pdfmm **newly** created files to something compatible with PoDoFo license. These files are currently in LGPL 2.1 (fixed), so they are currently incompatible with PoDoFo (LGPL 2.0+). This will occur independently on decisions on relicensing of PoDoFo, which you all know it's something I'm actively pursuing (but can happen later the merge); - (podofo github) Create a podofo-next branch; - (podofo-next) Check-in the above modified pdfmm into podofo-next; - (podofo-next) Continue development there an discussions in ML aiming for a PoDoFo 1.0 release. As you can understand, all of this it's not imminent. I hope everything can be done within july-august. If not, I will also have more time to dedicate to PoDoFo in september. Cheers, Francesco [1] https://github.com/pdfmm/pdfmm/blob/master/TODO.md On Thu, 5 May 2022 at 09:53, Christopher Creutzig wrote: > > Hi Francesco, > > Thanks for the confirmation, I was hoping that was the situation. Sorry for > the poor phrasing. > > What are your plans for the remaining steps before the back-merge, will that > happen in the pdfmm repository or in a branch in the new podofo one? > > > Cheers, > Christopher > > The MathWorks GmbH | Friedlandstr.18 | 52064 Aachen | District Court Aachen | > HRB 8082 | Managing Directors: Bertrand Dissler, Steven D. Barbo, Jeanne > O’Keefe > > > > -Original Message- > From: Francesco Pretto > Sent: Thursday, May 5, 2022 9:42 > To: Christopher Creutzig > Cc: Podofo-users > Subject: Re: [Podofo-users] Future ABI stability of PoDoFo > > Hi Christopher, > > On Thu, 5 May 2022 at 08:16, Christopher Creutzig > wrote: > > > > Backporting required parts of std::span and having a layer that switches > > between std::format and fmtlib shouldn’t be too hard, assuming these are > > only used internally and nothing in the API expects span inputs, for > > example. But would we require contributors to use a C++20 enabled compiler? > > > > > > Please note that what you suggest it's already in place in pdfmm: I use > fmtlib in place of std::format and a backported std::span. > > Thinking a little bit more about the topic, let's not argue too much about > this: for the API/ABI surface I will just stick to C++17 requirement and hide > the fact I'm using std::format and std::span. > > Cheers, > Francesco > ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Future ABI stability of PoDoFo
Hi Christopher, On Thu, 5 May 2022 at 08:16, Christopher Creutzig wrote: > > Backporting required parts of std::span and having a layer that switches > between std::format and fmtlib shouldn’t be too hard, assuming these are only > used internally and nothing in the API expects span inputs, for example. But > would we require contributors to use a C++20 enabled compiler? > > Please note that what you suggest it's already in place in pdfmm: I use fmtlib in place of std::format and a backported std::span. Thinking a little bit more about the topic, let's not argue too much about this: for the API/ABI surface I will just stick to C++17 requirement and hide the fact I'm using std::format and std::span. Cheers, Francesco ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Future ABI stability of PoDoFo
Hi Mattia, I definitely thought about ABI stability but I'm not super experienced how to ensure it for C++ libraries. I think the API review and hierarchy chances I will be helpful also to ensure there will be less ABI changes. I never fixed SONAME during compilation: at the right moment I may ask for some help. I'm also realizing that what is boiling in PoDoFo-next is already a C++20 library (I extensively use std::span[1] and std::format[2]), with the possibility of being able to compile with a C++17 compiler using some fillers. Aiming for inclusion in a distribution I should make sure the compilation defaults to C++20, with C++17 support that is only voluntarily/optionally enabled (and persisted in a the build configuration header) otherwise this may cause ABI issues when mismatching C++ compilation compliance level flags. Cheers, Francesco [1] https://en.cppreference.com/w/cpp/container/span [2] https://en.cppreference.com/w/cpp/utility/format/format On Wed, 4 May 2022 at 16:21, Mattia Rizzolo wrote: > > Hi (especially Francesco), > > Something that I don't think I've read in the past mails: do you have > any plans regarding ABI stability of PoDoFo? > > Currently there is no promise of ABI stability across versions, and as > such the SONAME also changes for each release, even if sometimes it > could have been avoided. > > > For me this is relevant because for each release the updates needs to be > manually approved by Debian's archive admins due to the changed soname, > which is something I would be happier without :) > > -- > regards, > Mattia Rizzolo > > GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. > More about me: https://mapreri.org : :' : > Launchpad user: https://launchpad.net/~mapreri `. `'` > Debian QA page: https://qa.debian.org/developer.php?login=mattia `- > ___ > Podofo-users mailing list > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Announcing PoDoFo Release 0.9.8
Hi Dominik, I synced the podofo repos[1][2] on github. You may be able to disable SVN access on sourceforge, but I can't help you more than pointing you this message[3]. Cheers, Francesco [1] https://github.com/podofo/podofo [2] https://github.com/podofo/podofo-svnold [3] https://sourceforge.net/p/forge/site-support/14343/ On Tue, 3 May 2022 at 15:25, Dominik Seichter via Podofo-users < podofo-users@lists.sourceforge.net> wrote: > Hi everyone, > > The PoDoFo developers are happy to announce the release of PoDoFo 0.9.8. > This release contains over 25 patches submitted by various contributors > (see SVN Log for details: > https://sourceforge.net/p/podofo/code/commit_browser). We encourage all > users to upgrade to this release. > > Tarball has been uploaded to: > https://sourceforge.net/projects/podofo/files/podofo/0.9.8/ > > Also, this will be the final release of PoDoFo based on the current > codebase. After the release we plan to introduce two major changes to > PoDoFo development. > > First of all, we will lock/close the current SVN trunk and switch PoDoFo > development to a more modern development platform ( > https://github.com/podofo/podofo), where we can leverage state of the art > development features such as Continuous Integration or Pull Requests. The > mailing list and webpage will stay on SourceForge as well as the issue > tracker. Still, we will open a new issue tracker for the new development > environment and gradually migrate open issues. We will share more news on > this, once the new development environment was set up. > > *Please do not use SVN anymore from now on. Any new development should go > GitHub. Please let me know if you need access.* > > Secondly and most importantly, we will replace the current codebase of > PoDoFo with the amazing work Francesco Pretto has done with pdfmm ( > https://github.com/pdfmm/pdfmm). pdfmm is based on PoDoFo but with an > improved and reworked API based on C++17 which we consider more suitable > for future development of PoDoFo. After rebasing PoDoFo on pdfmm, we plan > to release PoDoFo 1.0.0. > > Please note, PoDoFo 1.0.0 will be API incompatible (binary and in source > code) with PoDoFo 0.9.8. We expect migration steps to be necessary. PoDoFo > Tools are currently being ported to pdfmm as a showcase for the migration. > > Best regards, > Dominik > ___ > Podofo-users mailing list > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users > ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo Release / Outstanding Patches
Hi Dominik, yes, please continue with SVN for 0.9.8. I will do the sync on git. After you officially released, please shut down SVN access. About pdfmm: I want to make clear everybody that I'm not yet ready to merge back pdfmm into PoDoFo. The conversion of the tools is not yet finished, some API reviews are still pending, and I would like to make sure some few more features are checked in. Also it's very important for me to have the meeting before we officially move on. Anyway, to accelerate the process it we should possibly create a PoDoFo-next branch and make it master as soon as I'm done with the above schedule. Cheers, Francesco On Tue, 3 May 2022 at 14:23, Dominik Seichter via Podofo-users wrote: > > Hi, > > As there hasn't been any updates. I would suggest to package the release this > week and after that switch over to Git. > If necessary, we can still create a branch from Git (also in parallel after > the pdfmm merge back). > > Best regards, > Dominik > > On Mon, Apr 25, 2022 at 8:46 AM Dominik Seichter > wrote: >> >> Hi Mabri and developers, >> >> Just wanted to check if anybody plans to deliver any patches to PoDoFo SVN >> or if it would be a good time to package up the release. >> @Matthew Brincke : You mentioned you have something in the pipeline. >> >> As zyx has suggested, we should otherwise define a deadline. For me possible >> release dates could be this or next week or then only at the end of may. >> >> Best regards, >> Dominik >> >>> Especially @Dominik: IIRC (I've lurked here in the meantime and looked in >>> the issue tracker on SourceForge a few times), >>> there are some patches still outstanding which I'd like to test (using some >>> "poor man's CI/test automation" locally most likely) >>> and then apply to SVN trunk, which fix security issues/crashers, so that >>> I'd be grateful for considering them >>> necessary for the next release. I'm not currently doing other work (a day >>> job), so I think I can do this quickly, >>> I hope starting tomorrow (Sunday). For the other issues labeled "security" >>> I'd also like to see what I can do >>> (I hope to produce patches and then handle them like the others, could you >>> please do too?). > > ___ > Podofo-users mailing list > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo virtual meeting
Hello guys, I'm sorry, I made a mistake in assuming that Dominik was available in these weeks. I am not comfortable in holding this meeting without him, so let's just delay it (I just deleted the doodle). Still I think it was useful as we identified that Wednesday was preferred by most people. I'm talking with Dominik right now: most probably we will reschedule the event for Wednesday May 18th. I will update you soon. Cheers, Francesco On Tue, 3 May 2022 at 13:55, Dominik Seichter wrote: > > Hi all, > > Thanks for organizing this @Francesco Pretto ! > I am sorry to say that I cannot make it this week and/or the week after. > Sorry, for the short notice. > > Still, feel free to discuss next steps and do not hesitate to start the > meeting series without me. > > Best regards, > Dominik > > On Fri, Apr 29, 2022 at 10:24 AM Francesco Pretto wrote: >> >> Hello, >> >> I remember everyone to answer to the Doodle: >> >> https://doodle.com/meeting/participate/id/e5yK03qe >> >> So far the most voted day is next Wednesday, at 15.30 CEST. I think at >> this point that probably the event will be held within strict workdays >> (Mon-Thu, better exclude Friday). Since some people may want to join >> but prefer evenings, including one person that did patch reviews and >> may hold some stakes, I added another option on Wednesday May 11th, >> 17.30-19.00 CEST. I guess we all have a job, and that would basically >> be a late call of the day, possibly prolonging the work day a bit, and >> also people that can't have calls regarding PoDoFo during their job >> could at least get a (small) leave to finish job earlier that day and >> be able to join the meeting. I ask people that voted so far to also >> express availability/unavailability for that day, and add some more >> availabilities. I remind you that the scope of these doodles is to try >> to maximize participation and that there is also the yellow "if need >> be" option where you can state an availability that is not comfortable >> for you but still feasible. >> >> Thank you again! >> >> Cheers, >> Francesco >> >> >> On Mon, 25 Apr 2022 at 13:56, Francesco Pretto wrote: >> > >> > Hello PoDoFo maintainers/devs, >> > >> > I got some replies to the meeting poll and decided to create a doodle >> > based on the results, which I attached. Looking at results, there's seems >> > to be a preference on attending during working days/hours, so I put most >> > options on those time slots, with a couple exceptions (late Friday 6th and >> > morning Saturday 7th). >> > >> > https://doodle.com/meeting/participate/id/e5yK03qe >> > >> > What I would like to discuss, with a tentative schedule: >> > - [15min] Quick introductions, description of PoDoFo usage; >> > - [10min] pdfmm improvements over PoDoFo, propose to merge back; >> > - [25min] PoDoFo relicensing to more permissive license: yes/no, which one; >> > - [25min] PoDoFo development model, responsibilities, git adoption. >> > >> > Suggestions are welcome, but for such schedule I believe 1h and 15 min is >> > the bare minimum, and there may be no time to take decisions or discuss >> > many topics. We'll see, but please be open to stay few more minutes more. >> > Also on late Friday and Saturday morning there may be more time to discuss >> > topics more in depth, hence I created longer meeting slots in those days. >> > About which conference room to use: there's seems to be a slightly >> > preference of using Google Meet, which the second runner Microsoft Teams. >> > Google Meet works well without any application, so I think we should use >> > that this time, with possibility to switch to Discord for quick >> > chats/talks. >> > >> > Please, fill the doodle as well and thank you very much for your >> > participation! >> > >> > Cheers, >> > Francesco >> > >> > On Tue, 12 Apr 2022 at 20:55, Francesco Pretto wrote: >> >> >> >> Hello PoDoFo devs, >> >> >> >> last Sunday I wrote in another thread about an attempt to organize a >> >> PoDoFo virtual meeting. While Dominik told me such events were never >> >> organized nor needed to aid PoDoFo development, I think having one in >> >> this phase may help to revive interest in PoDoFo and be a very good >> >> opportunity to meet each other. I already had the chance to talk with >> >> Dominik face to face last week and it
Re: [Podofo-users] PoDoFo virtual meeting
Hello, I remember everyone to answer to the Doodle: https://doodle.com/meeting/participate/id/e5yK03qe So far the most voted day is next Wednesday, at 15.30 CEST. I think at this point that probably the event will be held within strict workdays (Mon-Thu, better exclude Friday). Since some people may want to join but prefer evenings, including one person that did patch reviews and may hold some stakes, I added another option on Wednesday May 11th, 17.30-19.00 CEST. I guess we all have a job, and that would basically be a late call of the day, possibly prolonging the work day a bit, and also people that can't have calls regarding PoDoFo during their job could at least get a (small) leave to finish job earlier that day and be able to join the meeting. I ask people that voted so far to also express availability/unavailability for that day, and add some more availabilities. I remind you that the scope of these doodles is to try to maximize participation and that there is also the yellow "if need be" option where you can state an availability that is not comfortable for you but still feasible. Thank you again! Cheers, Francesco On Mon, 25 Apr 2022 at 13:56, Francesco Pretto wrote: > > Hello PoDoFo maintainers/devs, > > I got some replies to the meeting poll and decided to create a doodle based > on the results, which I attached. Looking at results, there's seems to be a > preference on attending during working days/hours, so I put most options on > those time slots, with a couple exceptions (late Friday 6th and morning > Saturday 7th). > > https://doodle.com/meeting/participate/id/e5yK03qe > > What I would like to discuss, with a tentative schedule: > - [15min] Quick introductions, description of PoDoFo usage; > - [10min] pdfmm improvements over PoDoFo, propose to merge back; > - [25min] PoDoFo relicensing to more permissive license: yes/no, which one; > - [25min] PoDoFo development model, responsibilities, git adoption. > > Suggestions are welcome, but for such schedule I believe 1h and 15 min is the > bare minimum, and there may be no time to take decisions or discuss many > topics. We'll see, but please be open to stay few more minutes more. Also on > late Friday and Saturday morning there may be more time to discuss topics > more in depth, hence I created longer meeting slots in those days. About > which conference room to use: there's seems to be a slightly preference of > using Google Meet, which the second runner Microsoft Teams. Google Meet works > well without any application, so I think we should use that this time, with > possibility to switch to Discord for quick chats/talks. > > Please, fill the doodle as well and thank you very much for your > participation! > > Cheers, > Francesco > > On Tue, 12 Apr 2022 at 20:55, Francesco Pretto wrote: >> >> Hello PoDoFo devs, >> >> last Sunday I wrote in another thread about an attempt to organize a >> PoDoFo virtual meeting. While Dominik told me such events were never >> organized nor needed to aid PoDoFo development, I think having one in >> this phase may help to revive interest in PoDoFo and be a very good >> opportunity to meet each other. I already had the chance to talk with >> Dominik face to face last week and it was very useful and interesting >> to me: enlarge the meeting to previous and current maintainers, patch >> contributors and all people interested in PoDoFo development would be >> a good step in improving understanding who is using PoDoFo (and for >> what) and would certainly aid future steps being taken, other than >> helping to renovate a sense of community. Of course you already know I >> have several purposes about development PoDoFo, which possibly I would >> like to present and discuss. It's clear that PoDoFo has a small user >> base/community behind, but I still invite you to fill the form I >> created and state your interest/preferences: >> >> >> https://docs.google.com/forms/d/e/1FAIpQLSdAQrk_ktmgzJI_eZvevfvAlfG5EsttVftouNO3cfUKT2uUig/viewform?usp=sf_link >> >> Depending on the responses on this I will then prepare a doodle to try >> set a meeting date. Also I remind you I created an experimental >> #PoDoFo discord channel: >> >> https://discord.gg/SAVm4DVN >> >> Thank you for your support in this initiative! >> >> Cheers, >> Francesco ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Patch for pdfParser - findToken function
My report on pdfmm: 512.pdf -> OK 513.pdf -> OK 514.pdf -> OK rev.pdf -> FAIL big.pdf -> OK false.pdf -> OK I also created a big2.pdf (attached) that also fails on pdfmm but opens on Adobe, where the garbage is put just in between the numeric offset and the %%EOF. As you say, a better backward function should be created to handle such edge cases. I think for PoDoFo 0.9.8 we could focus on just handling the specific issue reported by Dennis, if possible with few lines of code and not breaking other pdfs. I'm sorry but I'm not available to work on PoDoFo 0.9.x codebase, but I will create test cases using the pdfs you created and fix it in pdfmm (which is candidate for merging to PoDoFo). Regards, Francesco On Wed, 27 Apr 2022 at 18:27, Michal Sudolsky wrote: > > Attached are 6 PDF files and all of them open well in 3 pdf viewers I tested. > >> >> so the backward search is correct, but it's better to limit it to >> "startxref". >> >> > Seems you are searching for a trailer right after xref (if I read that >> > part well). >> > >> >> Yes, correct, that was a cleaner solution: in my case it was useful to >> fix some spurious warnings as the commit message says. It also >> improved parsing performance. > > > Btw I noticed some typo here "Ooffset read position to the EOF marker if it > is not the last thing in the file". > >> >> >> > So is there actually some reason that for "i == 0" it is internal logic? >> > What if startxref is precisely PDF_XREF_BUF bytes before the last EOF >> > offset (m_LastEOFOffset)? >> > >> >> I didn't modify that code but I believe this was kind of a intended >> safeguard since the backward search is slow. Assuming one put a big >> amount of garbage also between "startxref" and "%%EOF" yes, what you >> say is true. > > > Yes, searching backward may be slow unless the whole file is loaded into > memory (which is not really good) but this can be also done by parts see at > bottom. And also it can search for both the trailer and startxref at once. > > 512.pdf gives error: > > PoDoFo encountered an error. Error: 8 ePdfError_InternalLogic > Error Description: An internal error occurred. > > That will be that "if( !i )" and it will probably throw such an error also in > pdfmm. I still do not believe this is really intentional (rather it is just a > bug). > > 513.pdf surprisingly works in podofo (trailer is not found by FindToken but i > is -1 so it seeks 513 bytes backwards where is subsequently found trailer by > IsNextToken after call to FindToken in ReadTrailer). > > 514.pdf same error as big.pdf. > >> We should test if Adobe handles arbitrary amount of >> garbage. >> > > big.pdf gives error (it has 1 MB of garbage so it is zipped): > > PoDoFo encountered an error. Error: 15 ePdfError_NoNumber > Error Description: A number was expected but not found. > > At the bottom of the call stack there is "Information: Unable to find trailer > in file." > > I also tested 1 GB of garbage (comments) and also this worked fine in the > mentioned 3 viewers. > >> Going back to the reporter issue: I don't know how to fix it in PoDoFo >> with a few lines patch, but if you don't think anything safe enough a >> better fix is doing like a did in pdfmm not reading "trailer" >> backward. Of course such change won't need being merged to pdfmm. > > > rev.pdf is working fine in podofo but when is applied patch from this email > thread then it gives error: > > PoDoFo encountered an error. Error: 15 ePdfError_NoNumber > Error Description: A number was expected but not found. > > It cannot find the trailer. > > Also I suppose rev.pdf cannot be opened in pdfmm. It has reordered xref and > trailer. Note that there is nothing in the pdf specification which says that > trailer and xref must be in particular order just that trailer is before > startxref. It also does not say how far from the end can be trailer or > startxref (only that %%EOF must be within 1024 bytes). > > Maybe the best approach would be to load chunks of file into memory from > backwards. Lets say first it loads the last 16 kB and searches for a token, > if not found it will discard this chunk and loads next 16 kB and so on so > even when there are GBs of garbage it will not drain the whole memory (of > course these chunks should somehow overlap because there can be "trai" at end > of one chunk and "ler" in previous chunk). > > But there is another case: > false.pdf gives error on podofo: > > PoDoFo encountered an error. Error: 20 ePdfError_InvalidDataType > > There is a "false" trailer in a comment. This means that it is not enough to > just search for a specific string but it needs to be aware of context whether > that string is in comment or not (this is the case for both trailer and > startxref). > > >> >> Cheers, >> Francesco ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Patch: Add missing guards to header files
Hi zyx, just to say that these patches in particular are not really hurting the process of merging pdfmm back to PoDoFO. They can be safely merged as I will either skip or merge partially. Fix -Wmemset-elt-size warnings looks important and it seems a fix I already did myself in pdfmm[1] (I'm using assumption that WCHAR strings are utf16 in Windows, which is guaranteed). Greetings, Francesco [1] https://github.com/pdfmm/pdfmm/blob/c6c07f29b6bf10ea2e7dee9f1eaf1ddc74e97aa6/src/pdfmm/base/PdfFontManager.cpp#L388 On Wed, 27 Apr 2022 at 07:45, zyx wrote: > > On Mon, 2022-04-25 at 16:25 +0200, Wolfgang Stoeggl via Podofo-users > wrote: > > here is a patch, which adds missing #include guards to the following > > header files: > > > Hi, > I believe it'll make sense to wait with patches until the sources are > moved to git and pdfmm is merged back into the PoDoFo sources [1], to > avoid merge conflicts and duplicated work. > > Similarly to your second patch (Fix -Wmemset-elt-size warnings). > > Both are kind of cleanup things, which can be void with the above work. > Just resubmit the patches (preferable in the GitHub), once the move to > git is finished. Look for such announcement here on the list. > Thanks and bye, > zyx > > [1] https://sourceforge.net/p/podofo/mailman/message/37609224/ > > > ___ > Podofo-users mailing list > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Patch for pdfParser - findToken function
On Tue, 26 Apr 2022 at 22:52, Michal Sudolsky wrote: > > You have this here too (just that seems pdfmm searches backwards only for > startxref): > > https://github.com/pdfmm/pdfmm/blob/master/src/pdfmm/base/PdfParser.cpp#L931-L932 > Yes, correct. Pdf standard is saying: ISO32000-1:2008, 7.5.5 File Trailer "Conforming readers should read a PDF file from its end" so the backward search is correct, but it's better to limit it to "startxref". > Seems you are searching for a trailer right after xref (if I read that part > well). > Yes, correct, that was a cleaner solution: in my case it was useful to fix some spurious warnings as the commit message says. It also improved parsing performance. > So is there actually some reason that for "i == 0" it is internal logic? What > if startxref is precisely PDF_XREF_BUF bytes before the last EOF offset > (m_LastEOFOffset)? > I didn't modify that code but I believe this was kind of a intended safeguard since the backward search is slow. Assuming one put a big amount of garbage also between "startxref" and "%%EOF" yes, what you say is true. We should test if Adobe handles arbitrary amount of garbage. Going back to the reporter issue: I don't know how to fix it in PoDoFo with a few lines patch, but if you don't think anything safe enough a better fix is doing like a did in pdfmm not reading "trailer" backward. Of course such change won't need being merged to pdfmm. Cheers, Francesco ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Patch for pdfParser - findToken function
Does PoDoFO crash without the patch? Just to know, because in pdfmm I have no issues, but I **heavily** cleaned/bugfixed that code, and for example I don't search backward the "trailer" token anymore, which is fishy and I believe is the source of your issues. Unfortunately not doing that is not a oneliner[1][2]. [1] https://github.com/pdfmm/pdfmm/commit/98e8e8c207db8f57bbf1423c1ebd7c78292a [2] https://github.com/pdfmm/pdfmm/commit/f771490b01a5d86c87891494c9b3adc5ed7e95fb On Tue, 26 Apr 2022 at 17:42, Dennis Voss wrote: > Hey, > > attached is a pdf-file that is failing to be parsed by PoDoFo and a patch > for that bug. > > Description: > > The pdf-file has comments between the EOF and the 'trailer' token. These > comments are 'longer' than the lRange (lookup range) provided to findToken, > so when we try to find the 'trailer' token we will end up somewhere in the > comments and fail to find the token. > > Therefore, if the token we are looking for is equal to 'trailer' we > resize the buffer accordingly (nFileSize - m_nXRefOffset), this should > always find the 'trailer' token. > > > I dont know about the findToken2 function. The same code can be copied > over to there, but* i didn't patch *findToken2. That function seems to be > a bandaid for some other issue already, so i dont want to mess with it... > (feel free to patch it too though, i think it has the same problem). > > > Best Regards, > > Dennis Voss > ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] [PROPOSAL] Relicense PoDoFo to Mozilla Public License 2.0
Dear Joerg, Mattia, PoDoFo devs, On Thu, 17 Feb 2022 at 12:57, Mattia Rizzolo wrote: > > FTR, the committers (which are not the authors, but SVN doesn't > distinguish between authors and committers, and for sure it's not an > indication of copyright ownership): > 1 ulricharnold001 > 2 hashimsaleem > 2 oleksa > [...] I finally completed a complete enlisting of all PoDoFo contributors, together with verified email addresses, based on SVN commit and mailing list messages. It has been quite a long task that I did in my free time. The result of this work can be viewed at the following link: https://docs.google.com/spreadsheets/d/1Fowb52N6xYpSDf_d6cfJtZeK85ZQmMMYqSeyV5syEwo/edit?usp=sharing On Thu, 17 Feb 2022 at 22:09, Joerg Sonnenberger wrote: > > That's exactly why I consider this whole > relicensing exercise overkill, even if I would certainly approve of the > result. > So far the amount of PoDoFo contributors is about 100 individuals. On a quick estimate done after redacting the document I believe that after filtering of outdated/covered contributions and non copyrightable ones the list can be reduced to around 40 individuals, which I think they should still be manageable to contact. It would certainly require a lot of time preparing formal requests, contacting people and tracking answers. Of course better be very sure about this step, the virtual meeting would be right place to discuss about this. Cheers, Francesco ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Test EncodingTest::testDifferencesEncoding() now properly fixed
I tried the code you supplied in pdfmm: if the found font has all the
required GIDs, and the standard14 Helvetica actually doesn't have all of
them so I used Arial as a fallback, I can already handle the text
correctly, see the attachment.
Cheers,
Francesco
On Sun, 24 Apr 2022 at 13:45, zyx wrote:
> PdfMemDocument doc;
> PoDoFo::PdfPage* pPage;
> pPage = doc.CreatePage( PoDoFo::PdfPage::CreateStandardPageSize(
> PoDoFo::ePdfPageSize_A4, false ) );
> PdfFont * pFont = doc.CreateFont( "Helvetica", false, false,
> false, PdfEncodingFactory::GlobalWin1250EncodingInstance());
> TVecFilters filters;
> PdfMemStream output(pPage->GetObject());
> output.BeginAppend(filters);
> PdfPainter painter;
> painter.SetPage(pPage);
> painter.SetFont(pFont);
>
> PdfString str;
> std::string ustr;
>
> str = PdfString("ěščřABCĚŠČŘ");
> ustr = str.GetStringUtf8();
> printf ("1) '%s'\n", ustr.c_str());
> pFont->WriteStringToStream(str, );
> pFont->WriteStringToStream(ustr, );
>
> painter.DrawText(10, 780, str);
> painter.DrawText(10, 740, ustr);
>
> str = PdfString((const pdf_utf8 *) "ěščřABCĚŠČŘ");
> ustr = str.GetStringUtf8();
> printf ("2) '%s'\n", ustr.c_str());
> pFont->WriteStringToStream(str, );
> pFont->WriteStringToStream(ustr, );
>
> painter.DrawText(10, 700, str);
> painter.DrawText(10, 660, ustr);
>
> painter.FinishPage();
> doc.Write("/tmp/test.pdf");
>
> output.EndAppend();
> printf ("%s: wrote %d bytes: '%.*s'\n", __FUNCTION__, (int)
> output.GetLength(), (int) output.GetLength(), output.Get());
>
>
test-pdfmm.pdf
Description: Adobe PDF document
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Experimental PoDoFo subversion repository conversion pushed to github
The repository rebuild has been performed. On Tue, 19 Apr 2022 at 10:01, Francesco Pretto wrote: > > I provide a first feedback: the conversion didn't supply the svn > metadata needed to link back git commits to svn revision (this is the > default behavior in svn2git, contrary to git-svn). I'm going to > rebuild the repository, together with a couple of edits. > > I will inform you when the procedure is done. > > Cheers, > Francesco > ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Experimental PoDoFo subversion repository conversion pushed to github
I provide a first feedback: the conversion didn't supply the svn metadata needed to link back git commits to svn revision (this is the default behavior in svn2git, contrary to git-svn). I'm going to rebuild the repository, together with a couple of edits. I will inform you when the procedure is done. Cheers, Francesco On Sat, 16 Apr 2022 at 23:56, Francesco Pretto wrote: > > Hello PoDoFo developers/users, > > I would like to inform you that an experimental PoDoFo conversion of > the subversion repository has been pushed to the official PoDoFo > github registry: > > https://github.com/podofo/podofo > > The conversion has been performed using the svn2git[1] tool using the > following commands: > > mkdir podofo > cd podofo > svn2git https://svn.code.sf.net/p/podofo/code/podofo --authors > ../podofo-authors-transform.txt > > The full result of this operation has been first pushed to the > podofo-svnold[2] reference repository that has been archived > (=read-only), while the main podofo repository is is basically the > same as the reference repository with the old branches purged. The > authors transform input file matching SourceForge users to real names > + emails is attached. Please, let us know soon if there were > macroscopic mistakes in the conversion. If you want your contributions > to be linked to your identity in github, create a github account if > you don't have one and set the address that were used in > transformation input file as your main address or as an additional > one[3]. > > At the present time, the PoDoFo git conversion is to be considered > experimental and will act as a mirror of the Subversion repository (if > the are more commits in svn I will push them preserving the SF > username transform). Dominik will take the next steps towards the > 0.9.8 release with regard to repository handling: it's up to him to > decide when closing the SourceForge subversion repository, but before > that happens don't create pull-requests as we can't have two > repositories running for the same project. IMHO, the earlier > Subversion access is closed the better, but we need some feedback on > the conversion first. > > A copy of this email has been sent to all the SourceForce committers, > including the very first contributors. I hope this will be a good > news, especially if you haven't been in touch with the PoDoFo > community for a long time! > > Best regards, > Francesco Pretto > > [1] https://github.com/nirvdrum/svn2git > [2] https://github.com/podofo/podofo-svnold > [3] > https://docs.github.com/en/enterprise-server@3.4/account-and-profile/setting-up-and-managing-your-github-user-account/managing-email-preferences/adding-an-email-address-to-your-github-account ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo virtual meeting
Hello guys, I remind stakeholders and all people interested in PoDoFo development in general to fill the form. It's just 5 very quick questions that will help us to roughly understand when organize the meeting during the week. Cheers, Francesco On Tue, 12 Apr 2022 at 20:55, Francesco Pretto wrote: > > Hello PoDoFo devs, > > last Sunday I wrote in another thread about an attempt to organize a > PoDoFo virtual meeting. While Dominik told me such events were never > organized nor needed to aid PoDoFo development, I think having one in > this phase may help to revive interest in PoDoFo and be a very good > opportunity to meet each other. I already had the chance to talk with > Dominik face to face last week and it was very useful and interesting > to me: enlarge the meeting to previous and current maintainers, patch > contributors and all people interested in PoDoFo development would be > a good step in improving understanding who is using PoDoFo (and for > what) and would certainly aid future steps being taken, other than > helping to renovate a sense of community. Of course you already know I > have several purposes about development PoDoFo, which possibly I would > like to present and discuss. It's clear that PoDoFo has a small user > base/community behind, but I still invite you to fill the form I > created and state your interest/preferences: > > > https://docs.google.com/forms/d/e/1FAIpQLSdAQrk_ktmgzJI_eZvevfvAlfG5EsttVftouNO3cfUKT2uUig/viewform?usp=sf_link > > Depending on the responses on this I will then prepare a doodle to try > set a meeting date. Also I remind you I created an experimental > #PoDoFo discord channel: > > https://discord.gg/SAVm4DVN > > Thank you for your support in this initiative! > > Cheers, > Francesco ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] Experimental PoDoFo subversion repository conversion pushed to github
Hello PoDoFo developers/users, I would like to inform you that an experimental PoDoFo conversion of the subversion repository has been pushed to the official PoDoFo github registry: https://github.com/podofo/podofo The conversion has been performed using the svn2git[1] tool using the following commands: mkdir podofo cd podofo svn2git https://svn.code.sf.net/p/podofo/code/podofo --authors ../podofo-authors-transform.txt The full result of this operation has been first pushed to the podofo-svnold[2] reference repository that has been archived (=read-only), while the main podofo repository is is basically the same as the reference repository with the old branches purged. The authors transform input file matching SourceForge users to real names + emails is attached. Please, let us know soon if there were macroscopic mistakes in the conversion. If you want your contributions to be linked to your identity in github, create a github account if you don't have one and set the address that were used in transformation input file as your main address or as an additional one[3]. At the present time, the PoDoFo git conversion is to be considered experimental and will act as a mirror of the Subversion repository (if the are more commits in svn I will push them preserving the SF username transform). Dominik will take the next steps towards the 0.9.8 release with regard to repository handling: it's up to him to decide when closing the SourceForge subversion repository, but before that happens don't create pull-requests as we can't have two repositories running for the same project. IMHO, the earlier Subversion access is closed the better, but we need some feedback on the conversion first. A copy of this email has been sent to all the SourceForce committers, including the very first contributors. I hope this will be a good news, especially if you haven't been in touch with the PoDoFo community for a long time! Best regards, Francesco Pretto [1] https://github.com/nirvdrum/svn2git [2] https://github.com/podofo/podofo-svnold [3] https://docs.github.com/en/enterprise-server@3.4/account-and-profile/setting-up-and-managing-your-github-user-account/managing-email-preferences/adding-an-email-address-to-your-github-account domseichter = Dominik Seichter lrosenthol = Leonard Rosenthol ringerc = Craig Ringer ulricharnold001 = Ulrich Arnold pierre_marchand = Pierre Marchand oleksa = Oleksandr Moskalenko pzent = Palmer Zent zyx = Milan Crha aja_ = Milan Crha mc-zyx = Milan Crha mabri = Matthew Brincke ceztko = Francesco Pretto hashimsaleem = Hashim Saleem mrdocs = Peter Linnell ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] [RFC] pdfmm 0.9.20 released and offer to merge back to PoDoFo
On Thu, 14 Apr 2022 at 07:52, zyx wrote: > I suggest to use a standard form of the copyright notices, thus any > existing tools can help to aid any discrepancies in this regard. The > SPDX notes are similarly short and easy to decipher. The above would > look like: > > /* > * SPDX-FileCopyrightText: (C) 2007 Dominik Seichter <> > * SPDX-FileCopyrightText: (C) 2020 Francesco Pretto <> > * SPDX-License-Identifier: LGPL-2.0-or-later > */ > > (note of removed "by" and no '/**' at the beginning - it's because > '/**' can be understood as a documentation comment for tools generating > developer documentation, where these license comments really do not > belong to). > Very good suggestion. My intention was of course having shorter, more maintainable headers: this SPDX format seems a better solution, we should adopt it instead. > Also, when it comes to it, the sources can be dual-licensed. There are > large/well-known projects doing that. > Yes, projects can be dual licensed and some notable ones do it but that is usually required in the case of mutually incompatible licenses. For example cairo is dual licensed in LGPL 2.1 + MPL 1.1 because MPL 1.1 is incompatible with LGPL. If you pick a more permissive license which is compatible with LGPL you don't have such issue and the dual licensing may be redundant (MPL2 for example is LGPL compatible). Of course dual licensing could help in case a more permissive license somehow is found to be incompatible with a future version of LGPL but that's something quite hard to even imagine. These comments belong more to the re-licensing thread, let's try to stick to that thread for licensing related discussions. Cheers, Francesco ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo on GitHub
On Wed, 13 Apr 2022 at 09:43, Dominik Seichter wrote: > > @Francesco Pretto : I have seen you have setup a few actions for the pdfmm > GitHub project: https://github.com/pdfmm/pdfmm/actions > Can we reuse them in the future on the podofo project as a starting point for > CI? > > If you want to experiment with github actions for 0.9.x, feel free to copy the workflows for linux and mac, which are using system/brew packages. The Windows workflow is dependent on pre built packages on external repositories with submodules. If the aim stay as I proposed to merge back pdfmm (which will be basically a cover-up) into a new PoDoFo-next branch, then you'll get the whole infrastructure. But before going forward with CI, I think the first task is to convert the subversion repo to git with full history. I already did it for pdfmm, and I have a "svntrunk" branch tracking latest commits: https://github.com/pdfmm/pdfmm/tree/svntrunk In the pdfmm repo it's currently lagging behind since I upgrade it when I merge patches, to not miss them. The conversion has been created with git-svn tools[1] and I update it with "git svn rebase" (which is necessary for the time the main development still happens in Subversion). I would highly prefer if have a similar layout in the new PoDoFO repository, with full Subversion history. I converted only trunk which in my opinion was/is enough (Subversion repo would still be preserved in SF). Let me know if you want me to push such base layout in https://github.com/podofo/podofo . After you can organize to maintain 0.9.x codebase yourself. Otherwise if you prefer to do some extensive checking and preserve history also for branches you can do the conversion with git-svn tools. In this case I still recommend to have a development git repository with only a single development branch as a copy of the SVN-trunk (for now), to not mess with obsolete SVN branches that otherwise will populate git branch list for the time being (with possibility of being deleted anyway), and a read-only git repository with branch history for preservation purposes. Cheers, Francesco [1] https://git-scm.com/docs/git-svn ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] PoDoFo virtual meeting
Hello PoDoFo devs, last Sunday I wrote in another thread about an attempt to organize a PoDoFo virtual meeting. While Dominik told me such events were never organized nor needed to aid PoDoFo development, I think having one in this phase may help to revive interest in PoDoFo and be a very good opportunity to meet each other. I already had the chance to talk with Dominik face to face last week and it was very useful and interesting to me: enlarge the meeting to previous and current maintainers, patch contributors and all people interested in PoDoFo development would be a good step in improving understanding who is using PoDoFo (and for what) and would certainly aid future steps being taken, other than helping to renovate a sense of community. Of course you already know I have several purposes about development PoDoFo, which possibly I would like to present and discuss. It's clear that PoDoFo has a small user base/community behind, but I still invite you to fill the form I created and state your interest/preferences: https://docs.google.com/forms/d/e/1FAIpQLSdAQrk_ktmgzJI_eZvevfvAlfG5EsttVftouNO3cfUKT2uUig/viewform?usp=sf_link Depending on the responses on this I will then prepare a doodle to try set a meeting date. Also I remind you I created an experimental #PoDoFo discord channel: https://discord.gg/SAVm4DVN Thank you for your support in this initiative! Cheers, Francesco ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Could someone tell me the encode type of HexString followed by Tj
On Tue, 12 Apr 2022 at 18:09, Michal Sudolsky wrote: > > Just note that text position really does not depend on "m" or "l" operators > like that code may misleadingly suggest (correct me if I am wrong): > You are 100% correct. ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Could someone tell me the encode type of HexString followed by Tj
On Tue, 12 Apr 2022 at 14:50, zyx wrote: > there exists a text extract tool [1], which is supposed to, well, extract > text from the PDF files. > [1] > https://sourceforge.net/p/podofo/code/HEAD/tree/podofo/branches/PODOFO_0_9_7_BRANCH/tools/podofotxtextract/ > Correct: albeit many text related operators are not handled, that is the code to look in PoDoFo. Cheers, Francesco ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Could someone tell me the encode type of HexString followed by Tj
Hello, <08CF372D> is an hexadecimal string, which is basically a hex encoded representation of a char/byte array. The exact encoding of this byte array is specified in the F1 font /Encoding key. PDF standard has optimizations to draw the glyphs representing the text as fast as possibile. Because of this reason, the logical text often can't be retrieved directly from from the TJ/Tj operators, and must be mapped to Unicode code points by using the /ToUnicode map of the font. It's also possible that the logical text can be reconstructed only by geometrical considerations, such as finding chunks of the string in the proximities and geometrically within the same line. It's a complex task and PoDoFo doesn't expose a high level API to perform such text extraction. Also the handling of the different predefined/custom encodings that the PDF standard allows to use or define is incomplete and sometimes buggy. A work is being done to expose a new API for text extraction that is working quite well. The API is to be expected to be introduced first in pdfmm (a fork of PoDoFo), with a proposed plan to merge it back to PoDoFo together all the required enhancements to handling of PDF encodings. Regards, Francesco On Tue, 12 Apr 2022 at 12:35, Alex wrote: > > Hi, > > When I opened a pdf file using podofobrowser.exe,if a pdfobject has a > stream object,podofobrowser.exe will show the content of the stream as the > following: > > > BT > > /F2 10.56 Tf > > 1 0 0 1 136.46 758.28 Tm > > 0 g > > 0 G > > [(pdf)] TJ > > ET > > > BT > > /F1 10.56 Tf > > 1 0 0 1 154.94 758.28 Tm > > 0 g > > 0 G > > [<08CF372D>] TJ > > ET > > > > In the first BT object,I know easily the text string is “pdf “ by ([(pdf)] > TJ),but it is difficult to understand [<08CF372D>] TJ in the second BT > object,could someone tell me how to understand [<08CF372D>],what encode type > is this. > > > > > Thanks, > > > Alex > > > > > > ___ > Podofo-users mailing list > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] [RFC] pdfmm 0.9.20 released and offer to merge back to PoDoFo
Hello Matthew, On Sat, 9 Apr 2022 at 23:36, Matthew Brincke wrote: > > 2) Decision on license of PoDoFo Tools: > PoDoFo Tools are currently GPL whereas the library itself is LGPL. This e.g. > makes it hard to copy from tools to the library. From my point of view, we > should align the license so that the tools have the same license as the > library (currently LGPL, for the future see separate discussion). > > I always understood this difference as having a purpose > (in my view, warning people off taking PoDoFo tools and making something > non-free out of them). > As I stated, separate licenses makes harder for all to possibly refactor tools functionalities into APIs, which should be always doable. This is the most convincing argument to me for having a single consistent license for tools and library. I add that tests and example code should be always extremely permissive. > >> 3) Merging back pdfmm in podofo / replacing podofo with pdfmm: >[...] there are some patches still outstanding which I'd like to test (using >some "poor man's CI/test automation" locally most likely) > and then apply to SVN trunk, which fix security issues/crashers, so that I'd > be grateful for considering them > necessary for the next release [...] As I mentioned before, my intention is to merge all latest PoDoFo patches into pdfmm (atm I am just lagging behind few ones) before pushing for a merge back to PoDoFo, with few exceptions for unnecessary ones. Nothing useful should be lost. > > 5) relicensing to MPL: > I am in general open to that, but let's keep discussion in separate mail > thread. > > I think I'd like to think/discuss more about that (at least it's copyleft?), > in its mail thread. > Yes, MPL 2.0 is still copyleft, but it's more permissive with regard to static linking. The thread is still there for discussions, and I invite you to add your opinion as well. I add that the challenge for PoDoFo is to stay relevant in a world where C++ libraries in general are less and less required, and I believe the license issue is also a key factor to keep its relevance in the years coming. Since a relicensing is going to be costly (few details on this coming very soon: I am almost finished with a complete list of all PoDoFo contributors), I asked Dominik if he would consider even more permissive licenses such as Apache/MIT. I'm waiting for his opinions on this on the thread, and I ask you to share your thoughts as well. Cheers, Francesco ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Could someone tell the encode type of the signature value
Hello, the actual data of /Contents is a byte array (encoded as an hexadecimal string, in your example) is historically/often a PKCS7 signature. This is described in "12.8.3.3 PKCS#7 Signatures as used in ISO 32000" in ISO 32000-1:2008. Nowadays the signatures are CMS[1] (Cryptographic Message Syntax) structures (often they are compatible with PKCS#7) as described in "12.8.3.4 CAdES signatures as used in PDF" in ISO 32000-2:2020. podofosign tool and litePDF[1] have examples dealing with PKCS7 structures. Greetings, Francesco [1] https://en.wikipedia.org/wiki/Cryptographic_Message_Syntax [2] https://litepdf.sourceforge.io/ On Thu, 3 Mar 2022 at 12:18, 工作邮箱 wrote: > > Hi, > I signed pdf successfully using podofo,but I don't know the encode type > of the signature value,the signature value likes as the following: > > /Contents<308206DC06092A864886F70D010702A08206CD308206C9020101310B300906052B0E03021A05 > > Could someone tell the encode type of the signature value? > >Kingly > regards， > > > > > > > > ___ > Podofo-users mailing list > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] platform question
You are right that comparisons should be done on the same document. Still the very basic behavior of PoDoFo when appending content is something I was really uncomfortable and that I dealt in pdfmm by automatically encapsulate the previous content of the page/XObject stream(s) with q/Q operator before the append. This is done by default, because users not knowing the PDF standard should not get unpredictable results when trying to do simple tasks such as adding text to a location, but the behavior is intended to be controlled by use of optional flags[1] (some behaviors still not implemented). More to come about pdfmm later (I'm almost about to begin porting of PoDoFo tools). Greetings, Francesco [1] https://github.com/pdfmm/pdfmm/blob/874914ee597d5f49a48c3d5d122288e889dea8ff/src/pdfmm/base/PdfPainter.h#L36 On Fri, 1 Apr 2022 at 08:03, zyx wrote: > > On Fri, 2022-04-01 at 12:28 +0800, 主义可以不同 via Podofo-users wrote: > > can you give me some advice? > > Hi, > what advice are you looking for, please? The files are not identical, > obviously, thus there's really a very little to advice. You should > compare apples and apples, not apples and oranges. A wild guess would > be that the file you modified (not created from start) left some > drawing matrix in the stack, which influenced your text (drew it "up- > side-down"). I know the Microsoft PDF printer does this. There can be > more PDF creators not closing their drawings with a clean state. > Bye, > zyx > ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] [RFC] pdfmm 0.9.20 released and offer to merge back to PoDoFo
On Mon, 21 Feb 2022 at 11:25, zyx wrote: > For a simplicity of the project > maintenance it still makes sense to keep them together, from my point > of view [...] Knowing that the tools > can be compiled when the core library API changes is an essential > thing, which can be achieved for free, just by keeping them in the same > code base. > Actually I agree with your point about simplicity. If people are more comfortable to know that tools can just be compiled with the new API of course I may evaluate do a last effort to port them, so they can still reside in the same repository. After a quick fly by, most are trivial, with the exceptions of podofosign and podofoimpose. It's a mechanical work and obviously at this time I know the API better. If I do the port work, I will not resist to normalize the coding style and reduce the use of C style programming as well ;) . Please understand that after the port I would still need to "recruit" people to ensure they actually work as intended. In short words: they need a maintainer who cares about them. Cheers, Francesco ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] [RFC] pdfmm 0.9.20 released and offer to merge back to PoDoFo
On Mon, 21 Feb 2022 at 08:53, zyx wrote: > > On Sun, 2022-02-20 at 22:04 +0100, Francesco Pretto wrote: > > Also there's a licensing problem: tools (and tests) are GPL. > > This basically makes sourcing code from them into the library > > impossible > > I do not think so. Maybe I was not clear enough, I will make an example. Some time ago I wanted to make a text extraction API: I looked at podofotxtextract[1] but tools are GPL so I could not just copy from there. Luckily enough podofotxtextract was quite simplistic/limited, but the point is clear: if I want to make turn a tool into an API, for the benefit of everybody, I can not because that would be move GPL into LGPL which is license incompatible (the other way is fine). > It's very common to have different parts of the code > base licensed under different terms. There's nothing wrong about that. There's nothing wrong, but this doesn't mean it's always convenient. For example test code: they are just snippets of code mostly using PoDoFo library in the right way. What's the rationale of enforcing copyleft (GPL) for such code? From my point of view, such code should be to most permissive license as possible, to the point of marking it clearly "public domain", so everybody just feel free to verbatim copy from it. > It's not only about the code, for example the user documentation is > under different license than the source code itself. Sure. But documentation is often licensed in different terms because source code license terms mostly don't apply with the nature of documentation. [1] https://sourceforge.net/p/podofo/code/HEAD/tree/podofo/trunk/tools/podofotxtextract/TextExtractor.cpp ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] [RFC] pdfmm 0.9.20 released and offer to merge back to PoDoFo
On Sun, 20 Feb 2022 at 19:05, zyx wrote: > but I understood you'd like my opinion > on the matter too, I guess because I help with the pending patches > (eeks, I track several patches on this mailing list to be > "reviewed"/committed) > That's very helpful maintenance work that will always be welcome. I still don't know if I will be able to do patches review in a timely manner, we'll see. As I explained several times I am more into active development with my priorities. > > 1) PoDoFo project should be split in two different subprojects, > While I understand your reason behind this, I'd rather not split it. I understand your point. But I state that I'm not currently unavailable to port PoDoFo tools to the new API, also because I don't use them so I would not be the right person to test if they still work or not. Also there's a licensing problem: tools (and tests) are GPL. This basically makes sourcing code from them into the library impossible, even if may possibly make sense. I'm very uncomfortable with this: if tools are in the same repository they should be the same license of the library, to not create such problems. Please also have a look to my proposal to relicense PoDoFo to (slightly) more permissive terms[1]. > My personal preference would be GitLab, but it's > really just the personal preference, because I work with it more. I think GitLab is a very good platforms too, but I also think that GitHub will give us a little bit more visibility, which is also important for an undermanned project like PoDoFo. > Sure, it's just about the web page, which can stay on the Source Forge, > together with the mailing list. > Sure. > Again, this is only my personal opinion. As you can see, your proposal > sounds good to me. > Thank you, I appreciate it. Cheers, Francesco [1] https://www.mail-archive.com/podofo-users@lists.sourceforge.net/msg04719.html ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
