Upgrade to printpdf 0.8 adds 37 new crates. For me, who is using printpdf for generating PDF from the code, the HTML/text layout functionality is needless. It is gated behind cargo features, but dependent crates are still loaded, even if features are not used.
Have you had considered to separate HTML/layouting code to separate crate, that would use printpdf as a backend? I do not know target users, but I can imagine, that because printpdf works well and has well chosen abstraction levels, its users started to ask having also HTML output. But, for me, rendering HTML to PDF, compared with generating PDF by machine and with reading/manipulating PDF, looks as a completely different usecase.
Upgrade to
printpdf0.8 adds 37 new crates. For me, who is usingprintpdffor generating PDF from the code, the HTML/text layout functionality is needless. It is gated behind cargo features, but dependent crates are still loaded, even if features are not used.Have you had considered to separate HTML/layouting code to separate crate, that would use
printpdfas a backend? I do not know target users, but I can imagine, that because printpdf works well and has well chosen abstraction levels, its users started to ask having also HTML output. But, for me, rendering HTML to PDF, compared with generating PDF by machine and with reading/manipulating PDF, looks as a completely different usecase.