You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Context. I am prototyping an alternative to Auto Multiple Choice (AMC): a set of free tools to define exercises, to compose exercises into exam papers and to grade the filled papers automatically. For more clarity, here are examples of AMC outputs. The main rationale of my project is to clearly separate components and data formats, for the purposes of enabling powerful automation (automatic exercise generation, automatic exercise composition, automatic grading and feedback).
I just discovered Typst. I think that it looks already great in its current state, its rationale seems very sane and I hope that it will enable it to become the de facto typesetter for most of our use cases in some years.
I would like to implement a Typst version of a program that is in charge of the generation of exam papers. More precisely, this program takes the following as inputs and generates the following outputs:
Inputs:
A full definition of the exam content (JSON object that follows some schema: a list of exercises, each exercises contains a set of questions, questions can have different types such as a Multiple Choice Question...)
A set of aesthetic properties about the paper to generate (A4 format, margin size, color palettes, etc.). Can be some JSON object too.
Outputs:
The exam sheet in some vector image format (typically PDF)
The location of the various forms that should be filled by the people that take the exam. Forms are rectangle-shaped.
This location is needed to automatically parse the filled exams later on (this is done by another component not described here).
This location should be similar to a (p, (x0, y0), (x1,y1)) tuple where p is a page number, (x0, y0) are coordinates of a corner of the rectangle, and (x1, y1) are coordinates of the opposite corner of the rectangle.
This output should be a JSON object that associates a location to each form identifier. Form identifiers are defined in the component input that contains the exam content definition.
Questions. I think that most of the features that I need are already in Typst but a way to export the location of some rectangles. I tried to play in Typst language with locate and query but I could not make it work. I did not find a way to export such locations in dedicated output file, either. Did I miss something, is this feature already implemented in Typst?
If this is not implemented already I am okay with modifying Typst to enable this feature. For my usage I do not especially need this feature to be in the Typst language itself, it would be totally fine for me to enable Typst to generate location metadata about specific objects (e.g., rectangles that have a label) in an additional output file. It is fine for me to use the typst executable but also to write my own executable that uses Typst as a library. Do you think that this feature is desirable for Typst's codebase? If so I would be very interested in your general design opinion on how to implement such a feature in Typst, for the purposes of increasing the chance that the changes are merged into Typst's codebase in the long run.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi!
Context. I am prototyping an alternative to Auto Multiple Choice (AMC): a set of free tools to define exercises, to compose exercises into exam papers and to grade the filled papers automatically. For more clarity, here are examples of AMC outputs. The main rationale of my project is to clearly separate components and data formats, for the purposes of enabling powerful automation (automatic exercise generation, automatic exercise composition, automatic grading and feedback).
I just discovered Typst. I think that it looks already great in its current state, its rationale seems very sane and I hope that it will enable it to become the de facto typesetter for most of our use cases in some years.
I would like to implement a Typst version of a program that is in charge of the generation of exam papers. More precisely, this program takes the following as inputs and generates the following outputs:
The exam sheet in some vector image format (typically PDF)
The location of the various forms that should be filled by the people that take the exam. Forms are rectangle-shaped.
This location is needed to automatically parse the filled exams later on (this is done by another component not described here).
This location should be similar to a (p, (x0, y0), (x1,y1)) tuple where p is a page number, (x0, y0) are coordinates of a corner of the rectangle, and (x1, y1) are coordinates of the opposite corner of the rectangle.
This output should be a JSON object that associates a location to each form identifier. Form identifiers are defined in the component input that contains the exam content definition.
Questions. I think that most of the features that I need are already in Typst but a way to export the location of some rectangles. I tried to play in Typst language with locate and query but I could not make it work. I did not find a way to export such locations in dedicated output file, either. Did I miss something, is this feature already implemented in Typst?
If this is not implemented already I am okay with modifying Typst to enable this feature. For my usage I do not especially need this feature to be in the Typst language itself, it would be totally fine for me to enable Typst to generate location metadata about specific objects (e.g., rectangles that have a label) in an additional output file. It is fine for me to use the
typst
executable but also to write my own executable that uses Typst as a library. Do you think that this feature is desirable for Typst's codebase? If so I would be very interested in your general design opinion on how to implement such a feature in Typst, for the purposes of increasing the chance that the changes are merged into Typst's codebase in the long run.Beta Was this translation helpful? Give feedback.
All reactions