This issue addresses how we might leverage the CCCS Associate CV database to better streamline our process of preparing CVs for bids and for distribution to clients.
Toward a ‘plain-text’ system of document production
The aim is to move CCCS away from reliance on Microsoft and similar word processing software and instead to utilize only plain text documents style and ‘prinedt’ as PDF using the LaTeX publication platform.
Marcus and I have little experience with LaTeX. In my limited use, I experienced minor challenges of learning more nuanced aspects of the system, such as 1) producing special characters (em dash, en dash, hyphen), 2) distinguishing between footnotes and end notes, etc. Marcus’ experience is limited only to reading about the system, but Marcus is familiar with the concept of markdown and he also likes (I think) the ability to distinguish between style and content that one gets with LaTeX (similar to web markdown and CSS). All of this is to say that I expect we’ll have a steep learning curve. In the grand scheme of things, however, these are minor issues; learning MS Office also required significant time investment (just ones that we all probably started from a young age).
Steps in automating document production
It is my understanding that we can define a reporting structure where we ‘print’ information into a plain text file, and then we could use LaTeX to ‘print’ that file to PDF. The process would look something like this:
Step 1: Define the structure and identify the database fields to be printed:
| Given |
Variable |
| {bold tag}Consultant Name:{/bold tag} |
%LastName%, %FirstName% |
| {bold tag}Education: {/bold tag} |
%Ph.D.Year% {tab}%Ph.D.Institution%, Major: %Ph.D.Major%, Minor % Ph.D.Major % |
| (edu. cont.) |
%MastersYear% {tab tag}%MastersInstitution%, Major: %MastersMajor%, Minor %MastersMajor % |
| (edu. cont.) |
%BachelorsYear% {tab tag}%BachelorsInstitution%, Major: %BachelorsMajor%, Minor % |
| {bold tagLanguages: {/bold tag |
%Langauge1% - Speaking: %SpeakingLevel%, Reading: %ReadingLevel%, Writing: %WritingLevel% |
| (lang. cont.) |
%Langauge2% - Speaking: %SpeakingLevel%, Reading: %ReadingLevel%, Writing: %WritingLevel% |
| (lang. cont.) |
%LangaugeN% - Speaking: %SpeakingLevel%, Reading: %ReadingLevel%, Writing: %WritingLevel% |
Step 2: Print the plain text file from database by identifying a source ID:
Database ID: 001
| Given |
Variable |
| {bold tag}Consultant Name:{/bold tag} |
Dennis, Aaron |
| {bold tag}Education: {/bold tag} |
2011{tab tag}Lunds Universitet, Major: Asian Studies |
| (edu. cont.) |
2004{tab tag}Pacific Lutheran University, Major: Anthropology, Minor: German |
| {bold tag}Languages: {/bold tag} |
German - Speaking: 4, Reading: 4, Writing: 3 |
| (lang. cont.) |
Swedish - Speaking: 2, Reading: 3, Writing: 2 |
| (lang. cont.) |
Mandarin Chinese - Speaking: 3, Reading: 2, Writing: 1 |
| (lang. cont.) |
Russian - Speaking: 1, Reading: 1, Writing: 1 |
Step 3: Print the plain text file with LaTeX to PDF
StyleSheet:TimesNewRoman
| Given |
Variable |
| Consultant Name: |
Dennis, Aaron |
| Education: |
2011 Lunds Universitet, Major: Asian Studies |
| (edu. cont.) |
2004 Pacific Lutheran University, Major: Anthropology, Minor: German |
| Languages: |
German - Speaking: 4, Reading: 4, Writing: 3 |
| (lang. cont.) |
Swedish - Speaking: 2, Reading: 3, Writing: 2 |
| (lang. cont.) |
Mandarin Chinese - Speaking: 3, Reading: 2, Writing: 1 |
| (lang. cont.) |
Russian - Speaking: 1, Reading: 1, Writing: 1 |
… even in this example we begin to encounter some series challenges: I don’t have a Ph.D. (so that field should not exist), and we need to be able to account for an unspecified number of languages (I know one guy certified to teach 8 languages and capable of conversing in 16!). Ideally, our system of printing would be able to account for such variation. Another challenge will be the handling of special characters (in addition to the dashes, there are also the ä,ë,ï,ö,ü,ñ,ç that the database seems to be able to handle, but that LaTeX may have more trouble to accommodate).
Where to go from here?
My idea is that Marcus and I would learn LaTeX by preparing “boiler plate” CV templates that would replicate these models. This shouldn’t be that difficult (though I could by wrong), and would involve a bit of work to learn the LaTeX form of markdown. My expectation is that figuring out alignment issues and table structures will be the most tricky aspect of this task.
I imagine Paul’s work will be the more challenging aspect of this request. Other than the conceptual process I defined above, I have no knowledge about how one would go about ‘printing’ database content to a text file, nor am I aware of the extent to which we can automate the process. I expect that, no matter what, each printed CV from the database would need some minor human editing work before printing (which is fine). As you will see, some of the CVs also call for information linked directly to ‘Scope of Work’ tasks, which would have to be written anew for each assignment. Please just let me know what is and isn’t feasible in terms of automating the data transfer.
Thanks for being open to exploring ways to realize my various ideas.
This issue addresses how we might leverage the CCCS Associate CV database to better streamline our process of preparing CVs for bids and for distribution to clients.
Toward a ‘plain-text’ system of document production
The aim is to move CCCS away from reliance on Microsoft and similar word processing software and instead to utilize only plain text documents style and ‘prinedt’ as PDF using the LaTeX publication platform.
Marcus and I have little experience with LaTeX. In my limited use, I experienced minor challenges of learning more nuanced aspects of the system, such as 1) producing special characters (em dash, en dash, hyphen), 2) distinguishing between footnotes and end notes, etc. Marcus’ experience is limited only to reading about the system, but Marcus is familiar with the concept of markdown and he also likes (I think) the ability to distinguish between style and content that one gets with LaTeX (similar to web markdown and CSS). All of this is to say that I expect we’ll have a steep learning curve. In the grand scheme of things, however, these are minor issues; learning MS Office also required significant time investment (just ones that we all probably started from a young age).
Steps in automating document production
It is my understanding that we can define a reporting structure where we ‘print’ information into a plain text file, and then we could use LaTeX to ‘print’ that file to PDF. The process would look something like this:
Step 1: Define the structure and identify the database fields to be printed:
Step 2: Print the plain text file from database by identifying a source ID:
Database ID: 001
Step 3: Print the plain text file with LaTeX to PDF
StyleSheet:TimesNewRoman
… even in this example we begin to encounter some series challenges: I don’t have a Ph.D. (so that field should not exist), and we need to be able to account for an unspecified number of languages (I know one guy certified to teach 8 languages and capable of conversing in 16!). Ideally, our system of printing would be able to account for such variation. Another challenge will be the handling of special characters (in addition to the dashes, there are also the ä,ë,ï,ö,ü,ñ,ç that the database seems to be able to handle, but that LaTeX may have more trouble to accommodate).
Where to go from here?
My idea is that Marcus and I would learn LaTeX by preparing “boiler plate” CV templates that would replicate these models. This shouldn’t be that difficult (though I could by wrong), and would involve a bit of work to learn the LaTeX form of markdown. My expectation is that figuring out alignment issues and table structures will be the most tricky aspect of this task.
I imagine Paul’s work will be the more challenging aspect of this request. Other than the conceptual process I defined above, I have no knowledge about how one would go about ‘printing’ database content to a text file, nor am I aware of the extent to which we can automate the process. I expect that, no matter what, each printed CV from the database would need some minor human editing work before printing (which is fine). As you will see, some of the CVs also call for information linked directly to ‘Scope of Work’ tasks, which would have to be written anew for each assignment. Please just let me know what is and isn’t feasible in terms of automating the data transfer.
Thanks for being open to exploring ways to realize my various ideas.