aboutsummaryrefslogtreecommitdiffstats
path: root/doc/user/dia_erro
blob: a04aae063c2fc3dfd1cf308c18ff7c17f97676eb (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
@Section
    @Tag { dia_erro }
    @Title { Errors }
@Begin
@PP
Lout normally produces an output file that will print without mishap on
any PostScript device.  However, some of the options of {@Code "@Diag"}'s
symbols are passed through Lout to the output file without checking,
including anything containing @Code "@Diag" lengths, angles, points, and
tags.  Any errors in these options will not be detected until the file
is printed.
@PP
The most likely errors are {@I syntax @I errors}, as in
@Code "outline { 0 0 [ 0 xsize }" for example, in which a @Code "]" is
missing; @I { type errors }, as in @Code "SE:: 45d" where the
following object should have been a point; and @I { undefined errors },
arising from labels misspelt or used before being defined.  Less commonly,
the options may all be correct but the figure is too large in some way:  too
many labels, too deeply nested, and so on.
@PP
When an error is detected, @@Diag arranges for the offending page to
be printed up to the point where the error occurred, with a message nearby
describing the error.  Printing of the document is then aborted.  It is
often quite easy to find the problem, because it lies in whatever should
have been printed next.
@PP
If you see {@Code VMerror} in an error message, it means that the printer
vmerror. @Index { @Code VMerror PostScript error }
is running out of memory.  In that case, one thing you can try is
@ID @Code {
"@Diag"
"    save { yes }"
"..."
}
This causes the memory used by @@Diag to be reclaimed as soon
as the diagram is printed, rather than at the end of the current page
as is usual.  However, if the diagram is nested inside some other
major Lout package, such as {@Code "@Graph"}, use of this option may
cause other PostScript errors.
@PP
If you see @Code "dictfull" in an error message, it means that you are
dictfull. @Index { @Code dictfull PostScript error }
using an old version of PostScript.  Increasing the @Code "maxlabels"
option of @@Diag (Section {@NumberOf dia_summ}) might fix the problem.
@PP
On other occasions your document might print without problems but you
see things that should not be there.  Here is a typical example,
reported by a user:
@CD @Diag
    margin { 0.3f }
    outline { shadowbox }
    shadow { 0.2f }
    paint { lightyellow }
    zindent { 0.4f }
{
    @Tbl
        marginhorizontal { 0.55f }
        aformat { @Cell A }
    {
        @Rowa
            A { QEVENT:: @Node paint { lightblue } { QEvent } }
        @Rowa
            A { QIMEVENT:: @Node paint { lightblue } halign { right } { QIMEvent } }
        @Rowa
            A { QKEYEVENT:: @Node paint { lightblue } { QKeyEvent } }
    }
    //
    @RVLCurveArrow from { QEVENT } to { QIMEVENT } bias { 1.5f }
    @RVLCurveArrow from { QEVENT } to { QKEYEVENT } bias { 1.5f }
}
The problem here is the two short lengths of straight line protruding
backwards beyond the point where the arrow starts to curve.  This has
occurred because the @Code TO labels are to the right of the point
where the curving begins; it can be corrected either by reducing the
@Code radius option, or else by decreasing @Code { zindent }.  Ideally
@Code "@Diag" would adjust options for you so as to ensure that the
diagram always look good; but this is quite difficult to do, especially
when space to turn in is tight or there is a choice of which option to
adjust, as in the example above.  So @Code "@Diag" just does a few
basic things and leaves the rest to you.
@End @Section