Support configurable inter-word spacing limits during justified line breaking
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 38/100
Direzione di ricerca
Start with BidiLine.processLine() and PdfDocument.writeLineToContent(), the two entry points named in the issue. Trace how candidate breakpoints and remaining width determine word spacing, then check the existing line breaking tests. Done means an opt-in policy selects legal breaks within the configured spacing limits while preserving default behavior and natural spacing on the last paragraph line.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Is your feature request related to a problem? Please describe.
When rendering justified, hyphenated paragraphs, OpenPDF chooses line breaks using text at its natural width. Once the line has been broken, the remaining width is distributed during justification.
This allows inter-word spacing to be increased, but the line-breaking algorithm does not consider placing an additional word on the line by reducing inter-word spacing.
For example, suppose two possible breaks produce:
- A hyphenated line requiring 130% inter-word spacing
- A line containing the complete next word requiring 90% inter-word spacing
The second result is typographically closer to the natural 100% spacing, but OpenPDF currently selects the first because the complete word does not fit at its natural width.
PDF supports negative word-spacing adjustments through the Tw operator, so the output format can represent the desired result. The limitation appears to be in line breaking, particularly BidiLine.processLine().
Describe the solution you'd like
Provide an optional justified line-breaking policy with configurable inter-word spacing limits, for example:
columnText.setMinimumWordSpacingRatio(0.70f);
columnText.setMaximumWordSpacingRatio(1.35f);
columnText.setPreferredWordSpacingRatio(1.00f);
For each line, the line breaker would evaluate legal breakpoints at:
- Word boundaries
- Available hyphenation points
For each candidate, it would calculate the inter-word spacing required to fill the line:
required spacing ratio = (available line width - glyph width) / natural space width
Candidates outside the configured minimum and maximum would be rejected. Among the remaining candidates, OpenPDF would select the one closest to the preferred ratio. A hyphenation penalty could optionally be applied so that otherwise similar candidates prefer an unhyphenated break. The last line of a paragraph would continue to use natural spacing, as it does currently. This should be opt-in, preserving the existing line-breaking behavior by default.
Describe alternatives you've considered
The alternatives appear to be:
- Forking OpenPDF and modifying BidiLine.
- Performing paragraph layout externally and drawing every line directly through PdfContentByte.
External layout would duplicate much of OpenPDF's handling of mixed fonts, inline formatting, bidirectional text, links, superscripts, hyphenation, and page/column transitions. A configurable implementation within OpenPDF's line breaker seems more reusable.
Your real name
Ioannis Rigopoulos
Additional context
The relevant behavior can be seen in:
- BidiLine.processLine(), which stops scanning when the next character exceeds the available natural width
- PdfDocument.writeLineToContent(), which calculates the final word and character spacing
The rendering stage already appears capable of emitting negative word spacing if a PdfLine has negative remaining width. The main change may therefore be to retain and score candidate breakpoints beyond the natural line width.
One possible initial implementation would compare:
- The existing word/hyphen break before overflow
- Hyphenation candidates
- The next complete-word boundary, if it fits within the configured minimum spacing
A paragraph-wide optimization could be considered later, but even a line-by-line candidate comparison would improve the current result considerably.
Example requirement:
- Minimum inter-word spacing: 70%
- Maximum inter-word spacing: 135%
- Preferred inter-word spacing: 100%
- Hyphenation enabled
- Lingua principale
- Java
- Stelle
- 4.4k
- Fork
- 714
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di LibrePDF/OpenPDF
-
bug
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
-
IndexOutOfBoundsException in PdfReaderForse già presa @andreasrosdalw l’ha presa 94 giorni fa. Apertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
-
`PdfSmartCopy` can take effectively unbounded time on nested shared Form XObjectsForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertabug
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
-
Difficoltà 4/5 1-2 giorni Idoneità per principianti 45/100
Tutte le issue di LibrePDF/OpenPDF
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
oracle/graalvm-reachability-metadata#11472 ·
I maintainer di solito rispondono entro 1 giorno
-
OkHttp versions 5.4.0+ no longer include baseline-prof.txtForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertabug
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 83/100
lysine-dev/okhttp#9828 ·
I maintainer di solito rispondono entro 1 giorno
-
status: waiting-for-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
spring-projects/spring-ai#7269 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 89/100
objectionary/hone-maven-plugin#1353 ·
I maintainer di solito rispondono entro 9 giorni
-
ClassNotFoundException: io.netty.channel.kqueue.KQueueEventLoop stack trace printed during native build on main (Netty 4.2 removed the class)Forse già presa @gastaldi l’ha presa oggi. Apertaarea/netty kind/bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
quarkusio/quarkus#57939 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno