Why I Started Building GraphCompose #18
DemchaAV
started this conversation in
Show and tell
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I started GraphCompose with a very innocent idea:
I wanted to generate my own CV in pure Java.
No huge framework.
No visual designer.
Just Java and PDFBox.
And then I discovered the classic PDF generation loop:
write coordinates → render PDF → open PDF → something is 4 pixels wrong → change coordinates → render again → question your life choices.
PDFBox was not the problem. It was doing exactly what I asked.
The real problem was that I was thinking like a human:
“I want a header, then a section, then a paragraph, then a table, and if it does not fit, move it properly.”
But the PDF API wanted drawing commands:
“Draw this text at x = 42, y = 713.”
That gap is basically why GraphCompose exists.
The idea became:
Describe document intent first.
Resolve layout second.
Render through a backend third.
So PDFBox is not the product.
It is one backend.
The engine should understand document structure.
The backend should understand drawing.
That is why GraphCompose can target PDF today, has DOCX work, and could eventually support things like SVG, images, slides, or other coordinate-based outputs.
I wrote the full story here:
"Read full story" (https://imminent-cantaloupe-888.notion.site/Why-I-Started-Building-GraphCompose-35d19b38347b8036be69e9f78cf8c329?pvs=149)
Would love feedback, especially from people who have suffered through PDF/report generation in Java.
Beta Was this translation helpful? Give feedback.
All reactions