CVTool: Automating Content Variants of CVs

The use of markup languages, especially LaTeX, to specify curricula vitae allows the structural organisation of information relating to an individual’s academic, teaching, and professional activities. For many, it is a way to easily maintain data in text format without worrying too much about the formatting or visual aspect of the document [2]. In addition, the titles of the sections, used to organise the CV information, can be seen as “tags” utilised to annotate the different parts, allowing for searching and filtering. This point of view was taken into account to plan a solution to overcome the need to customise the CV (i.e., generate specific versions), while maintaining the original document as a repository. This paper introduces CVTool and discusses the design of its filtering DSL as well as its implementation.

The biggest challenge is that these filters are not only based on the LaTeX commands used in the document, which allow identifying parts and subparts and their titles, but also the chronological information that must appear transversally in all items of the different sections. The same kind of filter should be specified when a theme filter based on keywords must be applied. This type of filter is essential when we need a tailored CV related to a certain period or subject. Furthermore, it is also possible to define the language in which the CV should be written. The result will then be a CV that maintains the original format but is written in the desired language and contains information relating to the desired sections and dates. It is understood that when applying these filters, there must be a concern to maintain the consistency of the CV structure.

While user-friendly platforms like LinkedIn or Europass simplify CV creation through predefined templates [3, 6], they often lack flexibility for deeper customisation. In contrast, LaTeX offers full control over structure and layout but requires technical expertise [7]. This gap between ease of use and adaptability highlights the need for a solution like CVTool, which combines LaTeX’s flexibility with dynamic content management capabilities. After this introduction, the article is divided into 5 more sections: Section 2 presents the created DSL; Section 3 explores the challenges related to Latex syntax when building the document parser; Section 4 presents the system architecture components; Section 5 is dedicated to an use case for demonstrating the tool; Section 6 concludes the paper by presenting details regarding the website deployment and outlining potential directions for future work.

This section examines the primary challenges encountered when parsing LaTeX documents and managing their content, particularly in the context of filtering, customising, and generating new versions of CV files. LaTeX typesetting language presents unique difficulties due to its mixture of structural commands, metadata, and content, which must be accurately processed while ensuring document integrity and consistency.

The system architecture presented in Figure 1 is composed of modular components designed for the efficient parsing, transformation, and generation of LaTeX-based CV documents.

At its core, the CV Parser component extracts and structures data from the given LaTeX template, which is then stored temporarily in the Internal Representation – a transient in-memory data structure that ensures consistency and fast access during processing. For that, the LaTeX context-free grammar is used to construct the CV Parser together with the Earley analysis algorithm and MyInterpreter interface provided by Lark. These two components have distinct roles in handling the document’s structure: the Earley parser provides the structural foundation by analysing the LaTeX grammar and building a tree that captures the document’s hierarchy and content. MyInterpreter allows for efficient processing of each LaTeX element by visiting the nodes generated by the Earley parser and converting them into a structured format that will be used as the Internal Representation. The parser manipulates the matched tokens from the parse tree and organises them into four distinct types of entries – command, element, LB, and RB – as defined in the grammar. Each token is processed and converted into a Python data structure named Dictionary, preserving essential information such as the content, hierarchical level, and contextual placement in the document. The parser constructs a structured and coherent internal representation by organising the parsed tokens into well-defined entries. This approach ensures consistent data handling across different templates, which is essential for uniform processing and accurate output generation in later stages. Each entry within the internal representation follows the structure outlined below:

• $\mathrm{■}$

  Id: A unique identifier that reflects the order of the elements within the document;

• $\mathrm{■}$

  Tipo: The entry type, such as “command”, “element”, “RB”, or “LB”;

• $\mathrm{■}$

  Valor: The actual content of the token;

• $\mathrm{■}$

  Nivel: The nesting level of the entry, indicating its position within nested structures;

• $\mathrm{■}$

  Section: The section of the document to which the entry is related, or empty if not applicable;

• $\mathrm{■}$

  Subsection: The subsection of the document to which the entry is related, or empty if not applicable;

• $\mathrm{■}$

  Reserved: A flag indicating whether the token is a reserved LaTeX token.

Following this structure, a complete LaTeX document is represented as a list of dictionaries within our internal representation.

To provide a clearer understanding of how the internal representation works, below is presented a small excerpt of LaTeX data and its corresponding structure after being parsed into the internal representation. This comparison illustrates how each LaTeX element is captured and transformed into its standardized dictionary format.

The corresponding internal representation of this LaTeX example can be defined as the following list of dictionaries:

Once the internal representation is constructed, the DSL Parser takes over by interpreting user-defined DSL queries. It validates their syntax and translates them into executable commands. These commands are handled by the Controller component, which orchestrates the flow of data, manages the system logic, and coordinates interactions with other modules [5]. The Document Generator component receives the processed data and converts it into valid LaTeX files, preserving the intended formatting and structure. The API Service acts as the communication layer between the back end and the front end, managing requests and responses. Finally, the User Interface enables users to input requirements, interact with the system, and retrieve generated documents, ensuring a seamless and user-friendly experience. For this project, the Back-End was developed using Python, leveraging its extensive ecosystem of libraries and frameworks in the field of Natural Language Processing. The Front-End was implemented using React, a widely adopted JavaScript library for building user interfaces.

The tool page (Figure 2) is the central workspace of the system, providing an interactive interface for users to customise and manage their LaTeX-based CV documents. This page is divided into two main sections: The file display panel on the right, where the uploaded LaTeX file is shown, and the query interface on the left, where users input commands to filter and manipulate the CV content. Upon uploading a LaTeX file, users can utilise the query input area to introduce specific commands, which are then processed by the system. Each query is added to a stack in the Query History, where the system provides colour-coded feedback: successful queries are highlighted in green, while failed ones appear in red, accompanied by an error message detailing the issue. This immediate feedback mechanism enables users to iteratively refine their CVs, with each validated query reflecting real-time updates in the displayed file. Once users are satisfied with the final version, they can download the customised LaTeX file directly from the page.

Domain Specific Languages (DSLs) are specialized programming languages designed to address the needs of a specific domain [4], offering abstractions and syntax tailored to that area. Compared to General Purpose Languages (GPLs) [8], which are designed for a wide variety of applications, DSLs focus on expressiveness and efficiency in handling specific tasks related to a particular area of expertise, reducing complexity and improving productivity [10]. Within this, DSLs play a critical role in bridging the gap between technical systems and domain-specific expertise, allowing non-programmers to engage with software systems in ways that are intuitive and directly aligned with their expertise.
The DSL developed for managing curriculum content in LaTeX provides users with four primary operations, “Show”, “Translate”, “Reorder”, and “Drop”. Each one serves a different purpose, yet still follows defined rules. Below, we present the available command structure.

This section presents a case study to illustrate the effect of a sequence of commands on a specific CV. Dr. John Smith, a researcher in Natural Language Processing (NLP), is applying for a position in a university’s Language Engineering department. To support his application, he must tailor his CV to meet the institution’s specific criteria. The original CV is shown below and includes various sections, not relevant to the target application.

The institution provides the following requirements for CV submission. Each requirement is addressed using one or more queries supported by the tool.

• $\mathrm{■}$

  AR-01: Focus on NLP-related education, research, and publications.
  Query: Show ’Education’, ’Work Experience’, ’Publications’

• $\mathrm{■}$

  AR-02: Exclude unrelated roles (e.g., volunteer work, unrelated teaching).
  Query: Drop ’Volunteer Work’, ’Teaching Experience’

• $\mathrm{■}$

  AR-03: Include only information from 2015 onward.
  Query: Show * Filtered by date >= ’2015’

• $\mathrm{■}$

  AR-04: Include only publications relevant to NLP.
  Query: Show * Filtered by section = ’Publications’ and theme = ’NLP’

• $\mathrm{■}$

  AR-05: Present sections in the following order: education, research, publications.
  Query: Reorder ’Education’, ’Work Experience’, ’Publications’

• $\mathrm{■}$

  AR-06: Provide both English and Portuguese versions.
  Query: Translate from ’en’ to ’pt’

After executing the defined queries, a new version of the CV LaTeX file is created, resulting in a new CV structure:

The developed CVTool provides a complete web solution for managing LaTeX-based Curriculum Vitae documents through a custom query language and structured processing pipeline. To ensure functional reliability, a suite of automated tests was implemented using the pytest framework. These tests validated the behaviour of the CV parser, the domain-specific query language interpreter, and the controller logic responsible for applying transformations and generating output files. The inclusion of these tests throughout development contributed to the system’s robustness and facilitates future maintenance.

Deployment was structured around Docker and Docker Compose to guarantee consistency across development and production environments. The backend and frontend services were containerised, with environment-specific configurations handled through dedicated .env files. This approach simplifies deployment and supports scalability. The system is publicly available and can be accessed at: http://cvtool.epl.di.uminho.pt, allowing users to explore the platform and evaluate its capabilities in real use cases.

To the best of our knowledge, there is currently no comparable tool offering a similarly integrated solution for LaTeX CV management. While this observation is made with due caution, it underscores the novelty and potential impact of the proposed system.

While the system achieves its intended goals, there is clear potential for further development. Enhancing query feedback through real-time syntax validation, introducing user accounts for persistent session management, improving LaTeX formatting recommendations, and supporting additional features such as template switching or change tracking are all viable next steps. Continued expansion of the testing framework and refinement of the document generation process will also strengthen the system’s reliability and user experience. These improvements represent a well-defined path for evolving the platform into a more comprehensive and adaptable tool for LaTeX CV management.