[reportlab-users] From intra-paragraph images to drawings?

[Henning von Bargen]

> From: Robin Becker <robin at reportlab.com>

> Subject: Re: [reportlab-users] From intra-paragraph images to

> 	drawings?

> all of my recent experiments have been about getting rid of fragments

:( they

> were introduced when I/we first started using markup because I/we

didn't know

> any better and they were fairly fast. In practice it would be better

to just

> mark the transitions from one style to another with action objects.

That way

> we could eliminate all the fragment style comparisons and a lot of

code where

> we check to see if the incoming frag changes font, font size, or some

other

> attribute.

> 

> In the box glue model we would then have boxes with text or other

content,

> glue and actions. There are various well known schemes for joining

these all

> together.

> 

> You are supposed to be able to make a paragraph out of frags and the

parser is

> not called when they are given. Currently there are only text

fragments and

> cbDefns (callbacks originally). The cbDefns have a kind which can be

img to

> get image handling or anchor for an anchor (as in the original a tag).

All

> other cbDefns are assumed to be proper callbacks with a function name

etc etc.

> Only the 'img' kind has a size and gets special treatment. Presumably

we could

> add another kind which has size that could as Andy suggests be created

> directly with special behaviours. Personally I don't find the idea of

> generating paragraphs directly from fragments all that attractive.

Having just

> slogged through the code to split fragment words that are over long

I'm not

> sure fragments are an easy way to do things.

> --

> Robin Becker

> 


That's interesting to hear.
I still remember that fiddling around with the fragments wasn't easy
when I
wrote the Wordaxe replacement (with hyphenation) for RL's Paragraph
class,
http://deco-cow.sourceforge.net/ 

Will the RL 3.0 paragraph get rid of the fragments?
That would mean I'll have to rewrite the Wordaxe Paragraph class as
well.

When you rework the RL Paragraph class anyway,
please do a bit of refactoring then.

I had pretty much trouble reusing the code as it's not as OO as it could
be.
For example, there are many functions defined at the module level (and
not
inside the class) that were called from inside the class functions;
making
inheritance impossible (at least in a clean way).

You could further help me (and probably others) if the Paragraph class 
and the fragments (or whatever will replace them) would know about
language
and auto-hyphenation (with an overridable no-op implementation).

FYI, Wordaxe knows the following extensions to ParagraphStyle:
    defaults = dict(_orig_ParagraphStyle.defaults.items())
    defaults.update ({
        'language':None,
        'hyphenation':False,
        'backColor':None,
        'kerning':False,
        })

The attributes have the following meanings:

"language" specifies the language name (string) or None if unknown.
Before using a language, the hyphenation for the language has to
be registered for wordaxe, telling the library which hyphenation
implementation to use, eg:
    wordaxe.hyphRegistry["de_DE"] = PyHnjHyphenator("de_DE")
The PyHnjHyphenator tries to load an OpenOffice dic file named
"hyph_%s.dic" % language, thus one should use something like
"de_DE" or "en_US" or "en_GB".

"hyphenation" specifies wether to use auto-hyphenation (True) or not
(False).
Note: The CSS attribute for this is called "hyphens", the value "auto"
means
to use auto-hyphenation. Perhaps using the latter is better.

"backColor" is for text-marker-like setting the background colour of
fragments.
BTW note the US style: "backColor" - this should be reworked to accept 
"backColour" as well.
None means transparent background, a string is a color accepted by the
RL 
parser, e.g. "yellow".
Note: The CSS attribute for this is called "background-color"
Perhaps using the latter or "backgroundColor" is better than backColor.

"kerning" means to use kerning. This is supported for TrueType fonts
only
and (being implemented in pure python) probably quite slow.

You could even go one step further and allow inherited Paragraph classes
to
define any attribute as an extension.

Regarding my comments about renaming the attributes from Wordaxe to CSS
standard:
Roberto Alsina's excellent tool "rst2pdf" uses Wordaxe; I don't know if
changing
the attribute names would break rst2pdf's API.
Maybe he or any other rst2pdf guru has a point?

Henning