Closed doctormo closed 1 year ago
I will let you know in an hour or so as I'm currently implementing exactly this. :)
Very happy to have asked!
I noticed that we both did the same edits turning nonstroke_color
to set_nonstroke
at the same time. But no issue with merging as the edits were identical :sweat_smile:
Outside note: I've added cmd_TM to the text api as it's needed for kerning.
It's in master now.
Great, integrated. Looks like your Stroke args are cast incorrectly:
const auto &nsarg = std::get<Nonstroke_arg>(e);
-> const auto &sarg = std::get<Stroke_arg>(e);
src/pdfdrawcontext.cpp line 948
So we have color controls, but non of the other graphical controls. Would you prefer me to copy what you've done here as a pattern for those?
const auto &nsarg = std::get
(e); -> const auto &sarg = std::get (e);
Fixed.
So we have color controls, but non of the other graphical controls. Would you prefer me to copy what you've done here as a pattern for those?
Yeah, thanks. The idea was to add serialization methods one by one as needed. Their implementation should be pretty much the same as for colors.
Many of the text style commands are the same as the drawcontext commands that are already written. I'd like to be able to share the code so there's not duplication for things like RG/rg, cmd_gs etc.
Is the best way to do this to create a graphics specific base class or side class?
OR
Perhaps we could create a DrawContext during render text to process all of those commands, maybe forcing in our own cmd_appender so they happen in the right order?
OR
Make render_text append directly to the master drawcontext cmd_appender instead of building a seperate string first, so graphics operators can be inserted by calling them mid-stream.
OR
Copy pasta all the graphics code?