Recent changes to feature-requests

Use a well-documented box model and clean up the code

H. von Bargen — Thu, 03 Sep 2009 10:24:46 -0000

Right now, wordaxe heavily uses the ReportLab paragraph code.
Unfortunately, this is quite complex and hard to understand;
furthermore there isn't any specification.

If wordaxe adopted the CSS 2 box model, then we had the specification for free, and we could rewrite the code accordingly.
This would have the additional benefit that HTML to PDF conversion would become easier and more exact.

Support widow/orphans control

H. von Bargen — Thu, 03 Sep 2009 10:18:55 -0000

Right now, Wordaxe does not provide widow/orphans control.
This limitation was accepted to create working split/wrap code without bothering with the additional complexity for this feature.

Fast kerning/stringwidth implemented in C

H. von Bargen — Thu, 03 Sep 2009 10:14:39 -0000

Note: This requires pure-python kerning to be fully implemented first.
RL has a fast C version of stringwidth.
For performance reasons, it would be useful to have the kerning (processing) needed for width calculations and rendering (TJ) done in C as well.

Kerning support

H. von Bargen — Thu, 03 Sep 2009 10:11:14 -0000

We now have kerning support for TrueType fonts.
It should be quite easy (I think) to add kerning for Type1 (AFM) fonts as well.
I estimate this could be done within 1 or 2 days.
However, there's a little difference in comparison with TTF:
For TTF fonts, the kerning info is already present when RL has loaded the font.
For AFM, RL extracts only the information it needs, not the kerning info (KP, KPX). So it seems necessary to monkey patch RL to avoid parsing the file a second time.
Here the relevant excerpt from the Adobe's AFM specification (see Adobe website http://www.adobe.com\):
"""
Kerning Data ... (Optional.) ... The section is delimited by the lines StartKernData and
EndKernData. Kerning data is supplied in two forms: track kerning and pairwise
kerning. They are treated as subsections within the kerning data section
and both sections need not be present.
...
Pairs-Wise Kerning
The pair-wise kerning data is surrounded by the keywords:
StartKernPairs integer
EndKernPairs
StartKernPairs0 integer
EndKernPairs
StartKernPairs1 integer
EndKernPairs
(Required if pair-wise kerning data are present.) integer indicates the number
of pairs to expect. StartKernPairs and StartKernPairs0 denote writing
direction 0; StartKernPairs1 denotes writing direction 1. An AFM file can
contain pair-wise kerning data for more than one writing direction, each
delimited by the StartKernPairs0 or StartKernPairs1 ... EndKernPairs.
There is one kerning pair per line. Each line begins with a keyword of the
form KP, KPH, KPX, or KPY.
KP name1 name2 numberx numbery
Name of the first character in the kerning pair followed by the name of the
second character followed by the kerning vector specified as an (x, y) pair.
The kerning vector is the amount by which to move the second character
relative to the first character to position it properly. The kerning vector is
specified in the standard character coordinate system. As with all metrics, in
order to use this vector it is necessary to scale it by (current point size)/1000.
KPH <hex1> <hex2> numberx numbery
Same as KP, but the byte strings needed to generate the characters are given,
rather than the names. hex1 and hex2 are hexadecimal values, enclosed in
angle brackets.
KPX name1 name2 numberx
Name of the first character in the kerning pair followed by the name of the
second character followed by the kerning amount in the x direction (y is
zero). The kerning amount is specified in the units of the character coordinate
system.
KPY name1 name2 numbery
Same as KPX, but in the y direction (x is zero).
"""
I think it should be enough to interpret KP and KPX.

Support RL 2.3 new style attribute borderPadding

H. von Bargen — Sun, 08 Feb 2009 18:11:54 -0000

The new attribute borderPadding in the RL standard paragraph implementation needs to be supported by NewParagraph.py as well.

Supressing hyphenation of literal inline text

Christoph Zwerschke — Sun, 08 Feb 2009 14:51:49 -0000

I'm using wordaxe indirectly through rst2pdf. In my stylesheet rst2pdf stylesheet I have set

["literal" , {
"parent": "normal",
"fontName": "stdMono",
...,
"hyphenation": false
}],

because I do not want inline literal text to be hyphenated. However, the hyphenation attribute seems to be ignored for inline styles.

I think something needs to be done in wordaxe to make this work, but I don't know the inner workings good enough to make a suggestion.

Hyphenate CamelCase words

H. von Bargen — Sun, 12 Oct 2008 08:51:14 -0000

Soemthing like CamelCaseWord should be hyphenated automatically by the BaseHyphenator: Camel- Case- Words

Support pyhyphen

H. von Bargen — Sat, 13 Sep 2008 16:59:29 -0000

The pyhnj hyphenation does not work well on my computer and returns wrong results.

Today I tested pyhyphen from http://pyhyphen.googlecode.com
which gives much better results.
It would be nice to support it in wordaxe.