Roadmap

[Mark Szepieniec]

I think there are two main features that could be implemented with reasonable effort, which would significantly enhance the project.

Multiple Styles

Firstly, there should be multiple style files, so that users can pick whichever one they like best, and so that not all users end up with the same style. Once we have multiple styles, we could set it up so that for instance

make pdf STYLE=blue_ocean

would build the pdf using the "style_blue_ocean.tex" ConTeXt style file. There might be a more elegant way to do this, but this is the most obvious way I can think of.

Producing multiple versions of multiple styles might be problematic, although I now have experience going from css to ConTeXt once, so if other people suggest existing ccs styles that they'd like to see, I can take a shot at translating them to ConTeXt. I can also add a converting.txt file that documents which css directives map to which ConTeXt commands.

Programmatic Content

The second feature I'd like to have at some stage is programmatic control of the contents. This would allow users to do for example

make pdf TYPE=academic

to include academic publications, or

make html EXCLUDE={address,phonenumber}

to make a html version without sensitive personal data such as address or telephone number, which can be safely put online. This would require the user to use pandoc's header attributes feature to mark sections of the resume as being subject to manipulation by the arguments to make, such as in the following example:

Publications   {#academic}
============

The final part would be a pandoc filter which reads the vaiable from the make command and makes the changes to pandoc's internal format before writing the output file(s).

Further Thoughts

These are the two main objectives I see now for this project, but all comments / feature requests / remarks / questions are welcome, either in their own issue, or as comments on this one.

Thanks for reading,

Mark

EDIT: Changed example style name to make clear that the styles would ideally be significantly different, not just simple variations of each other.

[SyedMusaAli]

Hey, i KINDA made a might night blue style, should i commit it? Nothing fancy, just converted your greenish tags to blue.

[Mark Szepieniec]

I think if it's a color change or something similarly simple, we should leave that kind of changes to the end user.

I believe the styles that the repository contains (or rather, will contain) should be significantly different from each other, and each should be a starting point for individual users to make their personal adjustments, if they prefer.

That said, I don't want to discourage you, so if you think what you have is a significant improvement to the appearance of the resume (even if the code change may be small), please do show it, and I'll consider adding it to the project :-)

[BryanQuigley]

I'm specifically interested in "Programmatic Content" (in fact I hope for it to the basis of a new web service).

Some of my early ideas:

• Be able to tag things (I was thinking ), and remove them per resume TYPE (similar to above)
• Be able to refocus resume based on a specific Job Description (ex: put keywords in common higher in bulleted lists)

Would these items make sense to be integrated into pandoc_resume or does it make more sense to have a separate project that handles these kinds of markdown modification and then just feeds it to pandoc_resume? Thanks for your feedback!

[Mark Szepieniec]

@BryanQuigley either way should be possible -- doing it within pandoc_resume implies writing a pandoc filter so you'd need to be familiar with that, whereas you'd have more freedom if you're programmatically modifying the markdown with whatever tool you're most comfortable with.