[scribus] Hyphenation

john Culleton John at wexfordpress.com
Mon Oct 31 19:21:24 UTC 2011


On Mon, 31 Oct 2011 14:36:11 +0000 (UTC)
Andreas Vox <avox at arcor.de> wrote:

> john Culleton <John at ...> writes:
> 
> > If you fit text to a non-rectangular shape then obviously the TeX
> > paragraph at a time justification becomes more difficult. But it
> > can be done. In "The TeXBook" and "TeX for the Impatient" there are
> > examples of fitting text to wineglass shapes, circles etc. using
> > the \parshape command described on page 101 in the TeXBook. The TeX
> > code expected for this tag is tedious, consisting of a long string
> > of starting point/line length parameters, one for each line. IMO it
> > would be easier to generate these values in a program and pass them
> > to TeX.
> 
> Yes, but a) it doesn't allow for holes in the shape and b) you have
> to guess the line height.
> 
> > 
> > The virtue of frontending TeX vs. just adopting the TeX paragraph
> > algorithm for Scribus is that the TeXcode is already there and it is
> > already debugged. You just have to generate the TeX tags correctly. 
> 
> You also have to make sure that Scribus and TeX are using the same
> fonts. AFAIK that's only feasable with LuaTeX which is still beta.
> Also, apart from LuaTeX, TeX exports its results only as PDF or DVI
> (or log output), so Scribus would have to parse the results to get
> the needed information.
> 
> We already have renderframes for TeX and we might expand that by
> providing parshapes, fonts and colors from Scribus to TeX. But
> renderframes wont work as a general solution for everyone.
> 
> > And all the input, text and tags, are expressed in plain text. The
> > incorporation of the huge TeX feature set can be done one tag at a
> > time. The Scribus programmer can quit whenever he/she gets tired. 
> 
> Trust me as a programmer, it's not that simple :-)
> 
> > In my experience rivers of text are not a problem with TeX. I don't
> > know if this is more TeX wizardry or just dumb luck. I will inquire.
> 
> I'm pretty sure that's luck. Of course, if you only have minimal
> white space the probability for rivers is also smaller.
> 
> 
> /Andreas
> 
> 
> ___
> Scribus Mailing List: scribus at lists.scribus.net
> Edit your options or unsubscribe:
> http://lists.scribus.net/mailman/listinfo/scribus
> See also:
> http://wiki.scribus.net
> http://forums.scribus.net
> 
> _______________________________________________________
> Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting
>               http://www.doteasy.com 

Han The Thanh, the creator of many modern improvements in TeX, says
this in his dissertation:

Rivers are vertical alignments of interword spaces in typeset text.
This phenomenon disturbs the uniformity of typeset text and distracts 
the reader’s attention from text contents. Usually rivers appear in
typeset text with loose interword spacing, as larger interword
spaces can easily form vertical “white strips” in typeset text. When
text is typeset with tight and uniform interword spacing, there is 
less chance for rivers to appear.

So it is probable that the overall excellence of TeX even margin (full
justification) typesetting reduces the presence of rivers, but does not
guarantee elimination. However any paragraph of any length with an
objectionable river can be adjusted via the \looseness tag. This tag
attempts to make the paragraph one line longer or one line shorter
(more than one line is possible but impractical) within the constraints
of the current set of rules. 

--------------------------------------------------------------------------------

So how would TeX typesetting attached to Scribus work? We need to
settle on luatex and not any form of LaTeX.  
1. First the process needs to be set up to work on one paragraph at a time.
 
2. Scribus would deliver the paragraph to TeX with the various necessary
presets preceding the text, as in my example previously cited (compare.pdf). 
TeX would typeset the paragraph. TeX already knows what the font and
font size is. 

3.The next step would reduce the resulting pdf to text with the line
endings maintained. a called program like Acroread could do this,
controlled by something like the Expect variant of Tcl/Tk.

4. Scribus would reimport the text version of the paragraph
and fully align every line except the last one. This would be so close
to the TeX setup that the result would be very close to a TeX document. 

5. Page/frame breaks would be the responsibility of Scribus, and would
be determined in advance of the TeX process. 

6.What about microtypography? This would be added on after the
reimportation. In other words it would be used during the
TeX process and then reapplied after the fact by Scribus to
reduce interword spaces to a standard amount. To make this work TeX
would be restricted to glyph extension only. All Scribus would have to
do is measure the length of the returned line, add in prorated extra
word space up to a predetermined amount, and then if more expansion was
required stretch all the glyphs by a predetermined amount.

6. If both TeX and Scribus are operating from a similar rule set the 
results should be identical.

A proof of concept should be easy enough. I will work on a test run
using the present capabilities of Scribus and importing a paragraph 
of text which has been preadjusted by TeX. 

But first I have to write my weekly political column or my editor will
be angry with me :<) 

 







-- 
John Culleton
Free list of books for self-publishers:
http://wexfordpress.net/shortlist.html

"Create Book Covers with Scribus"
http://www.booklocker.com/books/4055.html



More information about the scribus mailing list