* What happens if an undefined format is passed to C<form>? I'm
presuming (and hoping) that's a run-time error.
Currently treated as "", with internal warnings. Probably should throw an exception.
* In 'What a block art though...' (page 2) I don't think there's supposed to be a citrus fruit in:
That means that if we use a one-line field, it only shows as much of the data as will fit on one lime.
<grin>
* 'In For the table, sir, it shall be served...' (page 8) the first
example has C<\r> at the end of each name and play, making each
piece of data be 2 lines. The second, blank, line of each piece of
data presumably should be rendered entirely as spaces, so that
anything following it (admittedly nothing in this case) would still
be lined up correctly.
Perhaps you're forgetting that all output lines are automatically trimmed. A line that is nothing but whitespace (i.e. /\n\s*\n/) is reduced to "\n\n".
However:
» The line after "Othello" appears to be 2 spaces short. » There are 2 blank lines after "Richard III" instead of 1, and neither have any spaces after them.
I suspect these are whitespace niggles in the Perl->POD->HTML conversion process.
» There isn't a blank line after "Hamlet".
Newlines (and carriage returns) embedded in a data item are "preserved".
That is, they cause line breaks in the output. See the section on line-breaking for more detail on that.
Are those all mistakes? Actually, the last one sounds useful --
being able to put some kind of 'divider' between records but not
after the last one; is there any way of doing this with C<form>?
This is precisely why C<form> is a standard Perl function. When you need something more complex than it can handle natively, you fall back to Perl itself:
print form
"+-------------------------------------+",
"| Index | Character | Appears in |",
"|=====================================|",
join(
"|-------|--------------|--------------|\n",
map( { form
"|{=][[=}| {=IIIIIIII=} | {=IIIIIIII=} |",
$_+1, $name[$_], $play[$_] } 0..$#name)),
"+-------------------------------------+";to produce:
+-------------------------------------+
| Index | Character | Appears in |
|=====================================|
| | | Othello, The |
| 1 | Iago | Moor of |
| | | Venice |
|-------|--------------|--------------|
| | Henry, | |
| 2 | Earl of | Richard III |
| | Richmond | |
|-------|--------------|--------------|
| | Claudius, | Hamlet, |
| 3 | King of | Prince of |
| | Denmark | Denmark |
+-------------------------------------+Admittedly, it would be convenient if, for this relatively simple task, one could just write:
print form
:layout«tabular»,
"+-------------------------------------+",
"| Index | Character | Appears in |",
"|=====================================|",
:sep«|-------------------------------------|»,
"|{=][[=}| {=IIIIIIII=} | {=IIIIIIII=} |",
[EMAIL PROTECTED], @name, @play[$_],
"+-------------------------------------+";but *that's* precisely why C<form> is in a module, not a built-in -- so I can evolve it as the real needs of the community become apparent. I'll certainly contemplate adding this feature to the ToDo list.
* In 'And now at length they overflow their banks.' (page 6) in the
final recipe example, if there happens to be something with a long
list of ingredients but a short method then will the final format
output an unnecessary blank line?
No.
* In 'And mark what way I make' (page 3) this:
ellipsis (try tilting your head and squinting).
should be "colons" instead of "commas".
Argh. Yes.
* In 'Command our present numbers be muster'd...' (page 4) this reference to "accuracy":
... form tries to avoid displaying a number with more accuracy than it actually possesses ...
should probably be "precision" instead (the degree of granularity to which a number is specified, rather than how 'truthful' the number is).
I deliberately avoided "precision" since it's not quite the right word either in this situation.
Damian
