View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0017155 | Scribus | Typography | public | 2024-02-06 09:16 | 2024-02-06 12:28 |
| Reporter | PK | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Product Version | 1.6.2.svn | ||||
| Summary | 0017155: Better layout engine for Scribus | ||||
| Description | Hi, This is a proposal for ameliorating the Scribus layout engine for the case of justified text. I used Scribus for years for short documents and I wrote my first book today. My think is a retex of this job. The current layout is quiet enough good for poster or cover, but has deeply limits for a long text, such as in a book or long article. When you set up such a text, you have to pass again by hands the text for adjusting for being quite nice. It is a long job, not very precise and depending a lot of the know-how of the corrector. What does he do? He tries to find an balance between all the parameters (space width, space character, space inter-character) for being correct "from his point of view". This is a very hand-craft way of working, dependently of the talent of the correct and moreover, parameters such "feeling" which are not precise. There is yet a solution for this problem. A important part of this way of working can be integrated in a algorithm. I even think that all can be done, such as it is done in the reference layout engine: TeX. I don't want to flame, just to propose an amelioration for Scribus. The current way is good for most of the jobs, but can be improved for others. I propose to add a dedicated engine for theses cases. My idea is to copy in the same time the way of the corrector and the way of the TeX algorithm. There are 2 cases to consider: - paragraph level - page level (page means frame text and column, all what can be considered as an ensemble from the top to the bottom) A paragraph is composed of words, separated by spaces: w1 sp w2 sp w3 sp w3... wn. A word is composed of syllables and a word can be cut between them: s11-s12 sp s21-s22-s23 sp s31 ... sn1-sn2-sn3-sn4. You have to add punctuation, that is in fact a specific syllable, that, in the most case, can't be cut. This very poor vision is the base of the current algorithm. When Scribus justify, it cuts respecting the number of possible cuts, and then plays with the spaces for increasing or decreasing their width, respecting the authorized interval, to adjust the whole paragraph. In the most cases, it runs enough good, but it is very far from a perfect result! What I propose is to go very far from this algorithm. 1. I don't know for the all the language, but all the cuts are not equal. For instance, in French, you can't let alone the ultimate syllable when it is a "mute" syllable (often when the syllable ends with a 'e', like "homme = "hom-me", the "me" is just said in a shuffle. A counter-example is 'tortue', where 'tue' is normal syllable, that means that this word can be cut). Then, you have to have different cuts than a general cut. I guess that Scribus may have already such a mechanism, but I'm not sure. Then, you need to have: - normal cut: c1 - not recommended cut: c2 - the ultimate and desperate cut: c3 What means c2? For instance, the short word composed of 2 syllables should not to be cut, depending a lot of the width of the syllable. "Ami" (friend) let a single letter if you cut "A-mi" which proposes a bad effect layout. Then you have to collect a dictionary, like tor c1 tue A c2 mi hom c3 me You may be add other cut signs for others languages if needed. The idea is to create a hierarchy of possible cut, i.e. a weighting for the algorithm (such as TeX, called penalty in this case). This is only the beginning:) At this point, the algorithm knows where it can cut, to set up the text the most beautiful l possible. But the most beautiful l text is to have a white space regular AND with the same width of all the characters! Then, you have now to consider an incremental loop to test all the solutions to achieve this target. You have to adjust in the same time the space between characters, the character width (of course, that means that you work with vector fonts!), the space between words. IHMO, I thing the best way is to start with a reference width and to adjust all the previous dimensions compared with it. For a beautiful l result, the constraint should not be visible from eyes, then you can't un/shrink more than a limit (to determine, but I think you can overrun 5%). At this point, incrementing a loop, you can find the nearest dimension which fits all the constraints. This is what a corrector does by hands, but obviously many many less precisely! At this time, the look should yet quite near of the result of the TeX engine. For the 'page', you have to include a general loop for the page, respecting a balance with the conditions of the paragraphs, including moreover those of the page (orphan lines...). This loop can be an help, because you can adjust new parameters such as the interline space. If all the interline space moves, it can't be see from the eye if you respect the same condition as previously (not to be too much ambitious, to respect the previous space interline spaces). I think it is a challenge to do, because it needs a lot of work. But I thing i worst, because IHMO, it is what it misses the most at Scribus today to be a general purpose tool. For editing a book, TeX is today the best way, far from Scribus. But with this new engine, I think that the differences will be more complicated to find, because of the natural advantages of Scribus. I hope my explanations are clear. Do not hesitate to tell me to precise my idea if needed. | ||||
| Tags | No tags attached. | ||||
| Patch | No | ||||
|
|
improvements are for sure welcome. but you should be aware that there is a big difference between latex and scribus: on the one side, latex is used as a tool and can afford to be "slow". on the other side, scribus does the text layout in an interactive setting and needs to be very fast. as far as i know, latex does two full passes to achieve its outstanding results. scribus can't obviously do that... but it can probably do better! |
|
|
Thanks for your response. Yes, I talk about TeX to cite the reference (as layout result), not obviously in the way to do (even if I think it is quite difficult to have a nice result with a single pass only). And I don't talk about LaTeX, which is a double couch on TeX. I focus only on the engine (I personally use plain TeX). Anyway, a better approach than today for Scribus is to focus on paragraph with my method, which can help to get a better layout. The problem of speed is important, but it can be surrounded. You read only the visible pages and there are few, then the engine can focus on theses pages for the reader before to focus for all the pages. Even if the speed is a little bit more slow, it is less important. Furthermore, this engine is a specific evolution for dedicated case. I can imagine that people who use this solution can understand that the benefice needs a little sacrifice in performance and that people can wait during the modification (which should be not interactive, but decided by people, to control the operations). |
