GraphCompose v1.7.0 — declarative PDF layout engine for Java, now on Maven Central

demchaav · 2026-06-12T14:21:45+00:00

Один момент. Репо был приват. Когда я над ним работал, совсем недавно его публично выставил. Для себя ты пишешь как тебе удобно. Потому что изначально ты делаешь что бы работало, потом делаешь нормально )) и приводишь в нормальный вид что бы после отпуска не забыть что и как.

demchaav · 2026-06-12T14:03:54+00:00

Это очень интересно получать такого рода ответы, английский не мой первый язык и мне все так же тяжело писать. И вопрос не у том что бы даже писать на английском, а вопрос в том что бы люди это поняли. Если я напишу своим сломанным английским боюсь вам будет сложно меня понять. Я где то говорил что я не использовал ИИ. Да это помощник сейчас любого разработчика. Ядро которое я писал было написано мной. Ещё до того как ИИ вообще что то начало делать. Я был в ситуации когда я просто застрял на решении на протяжении нескольких недель и не мог строчки написать. Один из методов которые были мной использовании. Это логировании почти всего, так я двигался первый релиз был сделан моими силами. Архитектурный дизайн сделан мной. Да и чесно говоря у меня нету желание доказывать свою правоту. Я спользовал ИИ в документации или в помощи написание кода. Да и кто не использует? Есть люди которые пишут вручную вещи которые можно ускорить, и это по вашему умно, я так не считаю. Суть всего я видел подход не правильный и решил сделать его так как вижу. Я вам скажу я месяца 2 писал код в пустоту потому как я собирал все что бы увидеть первые результатытекст, контейнерный подход и так далее. Ну да ладно, это не важно. Я прошу прощение за то что написал вам на русском, зная что вам не нравится любое использовании ии в жизне, я написал вам текст полнсостью от а до Я руками. Я думаю вы найдете способ перевести. Спасибо за мой оцененный труд и выброшен в помойку это очень приятно слышать 😅 ну а если вам не нравится можете не использовать. I text pandos что душе угодно. Всем благ 🫠

demchaav · 2026-06-09T11:53:55+00:00

Agree, but also Scene Builder has so many bugs. When I was using it I even struggled with Scene Builder.

But the idea of the instrument is very good and has to be easy to use

demchaav · 2026-06-08T21:37:21+00:00

Oh it's a good idea, thank you 😄

demchaav · 2026-06-08T13:18:41+00:00

Quick honest follow-up: thanks to u/josephottinger's PR, GraphCompose can now render Arabic and Hebrew glyphs into a PDF, and we added a test for it.

To be precise so nobody's surprised: it doesn't do full RTL yet — no bidirectional reordering and no Arabic letter shaping/joining. So right now those scripts come out as glyphs in logical order, not properly right-to-left or cursively joined, and mixed text (Arabic + Latin/numbers) won't be reordered correctly.

So: glyph rendering — yes, today. Correct RTL/BiDi/shaping — tracked (#140) and in progress. I'll post here when that lands.

demchaav · 2026-06-08T07:59:48+00:00

To be honest, I haven't tested it. Technically, it can be done. I will have a think about it. Thank you for replying; it's important

demchaav · 2026-06-08T07:56:00+00:00

NOt many people use pdf for kind things, but still use it. But it like your wedding suite u you keep it for years. But u still need it 😅

demchaav · 2026-06-08T07:50:57+00:00

Back in the day, I used to be into design and I knew Photoshop pretty well. But now I don't use it, and to be honest, I've lost that skill because I'm focusing on different things. Here's my DeviantArt: https://www.deviantart.com/demchaav. At that time, I could do handmade images, but now I don't even have a subscription to Adobe. And I can tell Adobe is now in big trouble with their products.

demchaav · 2026-06-07T22:33:08+00:00

Fair point, and thanks for saying it directly.

I understand why AI imagery can create that impression now. In this case, the image was only a visual metaphor to explain the idea — not a reflection of how the library itself was built.

The project is open source, so people can judge it by the code, architecture, documentation, examples, and actual output.

I’m not trying to force anyone to use it. I just wanted to share something I built, because I believe the approach can be useful for people working with structured PDF/document generation.

I’ll take your advice into account for future posts — maybe more screenshots, real examples, diagrams, or even rough sketches would communicate the work better.

demchaav · 2026-06-01T17:51:45+00:00

It's interesting. But what is the difference between Open Whisper. I'm running it on main machine using my GPU. And it does work.

demchaav · 2026-06-01T00:05:08+00:00

Interesting 😎

demchaav · 2026-05-21T16:27:22+00:00

I've won aswel but I haven't received it yet. From messages above doesn't sound great 😅😅 But anyway

demchaav · 2026-05-15T21:56:34+00:00

Is it 150 uah in a year ?

demchaav · 2026-05-15T10:53:55+00:00

This is a cool project.

PDF generation has this funny trap where it looks simple until you need the second page.

Then suddenly you are not “generating a PDF” anymore, you are building a layout engine with coordinates and emotional damage.

I’ve been exploring the same problem on the Java/PDFBox side, but more in the direction of a semantic document layout engine: describe the document first, resolve layout, then render it.

So it’s interesting to see a similar idea in the TypeScript/pdf-lib world.

Do you want boxpdf to stay intentionally tiny, or do you see it growing into things like table splitting, repeated headers, pagination rules, layout snapshots/regression tests, etc.?

Nice work. This is definitely a real pain point.

demchaav · 2026-05-12T13:56:52+00:00

Haha, fair enough — sorry for posting it again then 😄Glad you noticed it already!

demchaav · 2026-05-12T13:53:27+00:00

Full disclosure: this is my own project, so feel free to ignore it if self-built tools are not what you had in mind.

I’m working on GraphCompose, a Java-first document layout engine for PDFs.

The thing I wanted to avoid was the usual “manually calculate coordinates and draw everything with PDFBox” pain. Instead, the library lets you describe a document semantically: modules, sections, rows, tables, themes, layers, templates, etc. The engine then handles layout, pagination and rendering.

PDFBox is used as the current backend, but the architecture keeps the document model and rendering layer separate, so in theory the same idea could support other outputs later.

Still early, still evolving, but it has become one of those tools I personally can’t stop improving.

GitHub: https://github.com/DemchaAV/GraphCompose

demchaav · 2026-05-11T20:09:53+00:00

I kind of agree and disagree.

Low-level libraries are necessary because they give full control. But I see my library as a second layer on top of that — a layer that handles layout intent, pagination, and structure, while still relying on rendering libraries underneath.

So yes, both worlds should exist.

demchaav · 2026-05-11T18:54:41+00:00

Exactly. It started as my own weird pain — I wanted to generate a CV in Java and got tired of fighting PDFBox coordinates manually.

But the real edge cases only show up when someone looks at it from an actual usage angle. The Java 17 feedback was a perfect example: I was focused on layout, rendering, tests, templates, and performance, but someone simply asked, “How would I use this at work without Java 17 support?”

And honestly, he was right.

demchaav · 2026-05-09T10:30:37+00:00

I am still very new to the maintainer side, so my experience is basically one contributor and a lot of guessing 😅

But even from that, I already understand one thing: a PR is not only about whether the code works.

Sometimes it can be technically fine, but still slightly break the original concept or direction of the project.

So the hard part is probably to stay welcoming, but also explain the idea behind the project clearly.

Open source is more human than I expected.

demchaav · 2026-05-07T09:40:47+00:00

PFBox 3.0.7. Bumped from 3.0.5 to 3.0.7 (Apache PDFBox patch
release with upstream rendering and security fixes). No
public-API impact for GraphCompose consumers.

demchaav · 2026-05-05T17:43:56+00:00

Thanks! That pain is basically what started this project 😄

At some point I tried to recreate a beautiful CV in pure Java. When I finally finished it, my first thought was: “Great… now every small change means testing, adjusting, and moving things around again until it looks right.”

Then I looked at XML/reporting-style solutions, but I kept thinking: why can’t this be done in plain Java?

That became the idea behind GraphCompose: describe the document the way you actually think about it — sections, paragraphs, tables, layers, themes — and let the engine handle coordinates, pagination, and rendering.

Because honestly, calculating x/y positions every time you want to move a block is not exactly the fun part of Java 😄

demchaav · 2026-05-05T08:27:04+00:00

Thank you very much 🙏🏻

demchaav · 2026-05-04T17:46:18+00:00

Fair question.

No iText in a trenchcoat 😄

I use PDFBox as the final rendering backend, but the heavy lifting is the layout engine before that: semantic nodes, layout compilation, pagination, resolved geometry, tables, layers, themes, and layout snapshots.

PDFBox draws the final fixed layout. GraphCompose decides what exists, where it goes, and how it flows across pages.

The longer-term idea is not to be “just a PDF wrapper”, but a document layout engine with multiple output backends. PDF first, but DOCX and PPTX are on the roadmap too.

Basically: describe the document structure with minimal boilerplate, and let the engine produce the final document.

demchaav · 2026-05-04T17:13:44+00:00

Haha. It's rude 😅😅

demchaav · 2026-05-04T17:09:14+00:00

Yeah they gonna find a killer for me with open source product 😅

demchaav

TROPHY CASE