On Tue, 24 Jan 2023 at 08:18, zyx <z...@gmx.us> 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
