Closed johannesjmeyer closed 3 years ago
Could the base class be independent of any parsing/preamble, and the custom classes be focused on the parsing?
I think if someone came to the project and saw that there wasn't a specific JournalFormatter
for their article, it would be useful to be able to manually declare
formatter = Formatter(wide, wide_width, fontsizes)
Or possibly even
formatter = Formatter(wide)
with a default value for fontsizes
and throwing an error for formatter.figure(wide=True)
if formatter.wide_width is None
In theory yes, but if you build it like Formatter(width, wide_width, fontsizes=10, set_rcparams=None, additional_preamble=None, ...)
you're essentially doing the same that you would do when subclassing Formatter
. I think subclassing the formatter is the more elegant (and flexible) way to achieve this. So I would add the CustomFormatter
first and then wait a bit until new journal types flock in to see if they indeed share so much common structure that unifying them makes sense.
The idea with the default values is good!
Sorry, I forgot that the preamble is used to load the fonts, so you're right it makes sense to include.
I would suggest AbstractFormatter
for the abstract base class and Formatter(width, wide_width=None, fontsize=10, additional_preamble=None, ...)
being usable, but it's just semantics so up to you! I think I got this preference from programming in Julia
Added in PR #11
There should be a custom formatter that can be used if one's documentclass is not supported by
rsmf
and one measures out the document for oneself. Parameters should includeIn the end, this would actually cover all the functionality of
rsmf
and one could think about making this the default way (so there would be no formatter class hierarchy and the package-specific logic would be in the parsing. @sp94, would this be what you were thinking about?