[reportlab-users] Bulleted Text not displaying

adam hyde adam at flossmanuals.net
Tue Oct 21 17:33:19 EDT 2008


that is pretty bizarre...what OS and browser?

adam

On Tue, 2008-10-21 at 14:28 -0700, Peter Mattingly wrote:

> I'm getting some odd behavior when I look at

> http://en.flossmanuals.net/, I only see the page source. I do filter

> via Privoxy (http://www.privoxy.org/) and NoScript

> (http://noscript.net/), but disabling both of these programs makes no

> change in the presentation.

>

> On Sat, Oct 18, 2008 at 6:53 PM, adam hyde <adam at flossmanuals.net>

> wrote:

> hi

>

> Would you consider using FLOSS Manuals for the docs?

>

> We have a good system in place, and we use Reportlab to gen

> the PDF for

> print ready source:

> http://www.flossmanuals.net

>

>

> adam

>

>

>

> On Fri, 2008-10-17 at 18:03 -0700, Peter Mattingly wrote:

> > "But i our favour, we do have a broadly accurate user guide,

> the

> > source to create it, and a ton of readable, working tests"

> >

> >

> > Granted. As much as I harp on the lack of documentation,

> this

> > documentation is miles above any other open source

> documentation I've

> > ever seen; With the statistically anomolous exception of

> larger

> > projects: Samba, Mplayer, Apache, etc; Which have financial

> backing in

> > some fashion, for the most part.

> >

> > "The only workable solution is a community effort, which I

> have been

> > pleading for on this list for years."

> >

> >

> > Nerd's aren't good at writing, in general. Me being the

> exception. I

> > had to work really hard to be as fluent with printed text as

> with

> > words; To be fair I have an unfair advantage of being

> naturally

> > pre-disposed to this type of discourse.

> >

> > "The source to the docs has been in every distro since

> launch until,

> > oh, about 3 weeks ago (you have to use svn now). They are

> just Python

> > scripts. This was our criterion for release 1."

> >

> >

> > I didn't mean that this was the first I've heard of doc

> patching in

> > *this* project, really in *any* project. Finding any

> dedicated effort

> > to create documentation for anyone with an open source

> project is

> > laudible. And asking for user input on documentation? I've

> never

> > even heard of any dev *proposing* such; They'll just bang

> something

> > together at the last minute, spelling, gramatically and

> factual errors

> > included; Rife with "...this should be obvious..." and other

> > wearisomly predictable and unhelpful catchisms that make

> their

> > projects terrible to behold. So when I say "This was the

> first I've

> > heard..." really it's worse than you thought.

> >

> > "If someone finds that the user guide doesn't explain

> something

> > clearly enough, and has *an hour to spare*, it would be

> great if they

> > could either (a) send in a *patch correcting or expanding

> it* (i.e. 20

> > lines to generate the right paragraphs in the guide); or (b)

> send in a

> > *test script or teaching example*. We can review and check

> these

> > things quickly."

> >

> >

> > Emphasis mine. So you're saying: if I want to "patch" (e.g.

> revise or

> > completely re-write from the ground up) a segment of

> documentation I

> > have to send in code? Before I say anything more about

> that, let me

> > quote from the user guide for a second:

> >

> > *The two attributes spaceBefore and spaceAfter do

> what they

> > say*, except at the top or bottom of a

> > frame. At the top of a frame, spaceBefore is

> ignored, and at

> > the bottom, spaceAfter is ignored. This

> > means that you could specify that a 'Heading2' style

> had two

> > inches of space before when it occurs in

> > mid-page, but will not get acres of whitespace at

> the top of a

> > page. These two attributes should be thought of

> > as 'requests' to the Frame and are not part of the

> space

> > occupied by the Paragraph itself.

> >

> > *The fontSize and fontName tags are obvious*, but it

> is

> > important to set the leading. This is the

> > spacing between adjacent lines of text; a good rule

> of thumb

> > is to make this 20% larger than the point size.

> > To get double-spaced text, use a high leading. If

> you set

> > autoLeading(default "off") to "min"(use

> > observed leading even if smaller than specified) or

> "max"(use

> > the larger of observed and specified) then an

> > attempt is made to determine the leading on a line

> by line

> > basis. This may be useful if the lines contain

> > different font sizes etc.

> > (Page 62 of the user guide, section 6.1 )

> >

> >

> > "The two attributes spaceBefore and spaceAfter do what they

> say"

> >

> > Oh they do, do they?

> >

> > So in this context we're talking about Paragraphs and their

> associated

> > style's correct? So a style would dictate certain

> properties of the

> > Paragraph and the text they contain right? So spaceBefore

> and

> > spaceAfter provide some variables for manipulating space

> having to

> > deal with the paragraph; But what space? Perhaps spacing

> between

> > letters in the text? Vertical space between paragraphs?

> Horizontal?

> > Spacing between lines of the text in the paragraph?

> Something else?

> >

> > From the rest of the text it's implied that this is padding

> within the

> > frame surrounding the paragraph.

> >

> > You can see where some of my frustration comes from.

> >

> > Now here, I'll provide a little rewrite for the second case

> I've

> > cited:

> >

> > The fontSize and fontName attributes, set size of

> the font

> > being used (e.g. size 12, 16, 20, etc) and the name

> of the

> > font being used when creating text (e.g. Times New

> Roman,

> > Verdana, etc) respectively.

> >

> > It isn't perfect and probably could use some revision and

> editing.

> > But it's quite a lot better than "The fontSize and fontName

> tags are

> > obvious". But in order to submit my revision I have to

> figure out how

> > to embed it in Report Lab programming code? That's

> ridiculous.

> >

> > I'm currently a student learning how to do more with Report

> Labs, I'm

> > not experienced enough with your conventions to create clean

> portable

> > code. But at the same time, I'm able to revise and

> elucidate a

> > section of the user manual with perfect clarity and a few

> minutes

> > time. This would not be the case with programmtically

> creating a

> > similar solution. If the time I've spent so far is any

> indication,

> > such a project would require *multiple hours* of work to

> fully

> > understand the entire process. I suspect I've found an

> inefficiency

> > in the process of the community driven documentation you're

> trying to

> > create.

> >

> > I can however make changes to a Wiki, which is a much

> simpler approach

> > that others have taken to create community editable

> documents -

> > including user documentation. The experience is akin to

> making a post

> > on a forum or writing a letter, rather than programming.

> >

> > I would recommend Media Wiki

> (http://www.mediawiki.org/wiki/MediaWiki)

> > which is used with Wikipedia. If that's too much

> administrative

> > overhead (too much for me at least!), you can use any one of

> these

> > others:

> >

> > http://en.wikipedia.org/wiki/Comparison_of_wiki_software

> >

> > Some of the better solutions are TiddlyWiki and DokuWiki for

> a simpler

> > approach. I'm running DokuWiki and I'm very happy with it.

> I've

> > heard nothing but good things about TiddlyWiki.

> >

> > Thank you for taking the time to talk with me about these

> issues. I

> > hope to be of some help in the future. Report Labs is one

> of the few

> > programmatically accesible methods I've found for creating

> highly

> > formatted output for more than report creation; Which seems

> to be all

> > that other techies seem to aspire their output to be. ><

> >

> >

> > On Mon, Oct 13, 2008 at 11:24 PM, Andy Robinson

> <andy at reportlab.com>

> > wrote:

> > 2008/10/13 Peter Mattingly

> <pmattingly at mail.csuchico.edu>:

> > > You know what I mean though? Sufficient technical

> > documentation is one huge

> > > hurdle that OSS in general has to get over before

> any sort

> > of general (read:

> > > Non-maddeningly frustrating) adoption can take

> place.

> >

> >

> > You're correct; it is a weakness. (But i our

> favour, we do

> > have a

> > broadly accurate user

> > guide, the source to create it, and a ton of

> readable, working

> > tests).

> > But it also

> > takes a heck of a lot of time - more than

> maintaining

> > the code does. It's not just documenting new

> features, it's

> > constantly

> > pruning and editing everything which may be affected

> by a

> > change. The only

> > workable solution is a community effort, which I

> have been

> > pleading for on this

> > list for years.

> >

> > >

> > > And...you can patch the docs? First I've heard of

> doing

> > that...

> >

> >

> > The source to the docs has been in every distro

> since launch

> > until,

> > oh, about 3 weeks ago (you have to use svn now).

> They are

> > just Python

> > scripts. This was our criterion for release 1.

> >

> > If someone finds that the user guide doesn't explain

> something

> > clearly enough,

> > and has an hour to spare, it would be great if they

> could

> > either (a) send

> > in a patch correcting or expanding it (i.e. 20 lines

> to

> > generate the right

> > paragraphs in the guide); or (b) send in a test

> script or

> > teaching example.

> > We can review and check these things quickly.

> >

> >

> > Best Regards,

> >

> > --

> > Andy Robinson

> > CEO/Chief Architect

> > ReportLab Europe Ltd.

> > 165 The Broadway, Wimbledon, London SW19 1NE, UK

> > Tel +44-20-8544-8049

> >

> > _______________________________________________

> > reportlab-users mailing list

> > reportlab-users at reportlab.com

> >

> http://two.pairlist.net/mailman/listinfo/reportlab-users

> >

> >

> >

> > _______________________________________________

> > reportlab-users mailing list

> > reportlab-users at reportlab.com

> > http://two.pairlist.net/mailman/listinfo/reportlab-users

>

> --

> Adam Hyde

> Founder FLOSS Manuals

> http://www.flossmanuals.net

>

>

> _______________________________________________

> reportlab-users mailing list

> reportlab-users at reportlab.com

> http://two.pairlist.net/mailman/listinfo/reportlab-users

>

>

>

--
Adam Hyde
Founder FLOSS Manuals
http://www.flossmanuals.net



More information about the reportlab-users mailing list