Getting warnings about graphics outside a block

[tbrowder]

I'm trying to track down where the warnings are originating, but the page prints fine. I am using nested graphics subroutines on a PDF page object, and that may be confusing the parser because I cannot find any obvious graphics outside a block except calling a sub within a graphics block.

If it's just a warning (which the Ops.rakumod file says it is), maybe you could enable an option to quell such warnings.

First set of warning lines from STDERR:

unexpected operation 'S' (Stroke) used in Page context, following 'h' (ClosePath)
  in block  at /home/tbrowde/.raku/sources/7B3C2E4E0F0B35CB54ADEBD7DCBFD6FBFA5D8783 (PDF::Content::Ops) line 1039
... for 150+ more entries

From the current code, here's an example of one sub called inside another in a graphics block:

sub draw-color-wheel(
    :$cx!, :$cy!,
    :$radius!,
    :$page!,
    ) is export {
    # a hex wheel of different-colored triangles centered
    # on the circle defined with the inputs

    $page.graphics: {
        .Save;
        # clip to a circle
        #draw-circle $cx, $cy, $radius, :$page;

        my $cnum = 0;
        #my $stroke-color = color Black;
        my $stroke-color = color White;
        my $stroke = True;
        for 0..^6 {
            my $angle = $_ * 60;
            ++$cnum; # color number in %colors
            my $fill-color = %colors{$cnum};
            draw-hex-wedge :$cx, :$cy, :height($radius), :$angle, :stroke,
                           :fill, :$fill-color, :$stroke-color, :$page;
        }
        .Restore;
    }
}

Finally, here is a simplified call tree, starting from the top entry in a script, then calling subs in a module:

my PDF::Lite $pdf .= new;
my $page;
for @text {
    $page = $pdf-add-page;
    make-badge-page @args, :$page;
        calls ==> make-label @args2, :$page;
                      calls ==> make-cross @args3, :$page;
}

[dwarring]

The unexpected operation warnings has a silly bug, which I've just fixed with PDF::Content 0.8.6, it was reporting two operators, back, rather than the immediately preceding operator. Please upgrade. You will still get the warning, but the message should hopefully be informative, and less misleading.

These checks can be disabled by calling page.gfx(:!strict) before adding any graphics to the page.

The PDF standard does have a recommended order of operations. In practice, a lot of drivers don't follow this, and get away with it, but it's good to keep the checks in place if possible.

Strict checking can also be done later using the PDF::Class script pdf-checker.raku --render --strict my.pdf

[dwarring]

Also, the running the script pdf-content-dump.raku might help with tracking done the error. warning For example:

 raku -I. `which pdf-content-dump.raku` --raku /tmp/tst.pdf
# **** Page 1 ****
.Save();
  .BeginText();
    .SetFont("F1", 16);
    .ShowText("xxx");
    .SetTextLeading(17.6);
    .TextNextLine();
  .EndText();
Unexpected operation 'h' (ClosePath) used in Page context, following 'ET' (EndText)
  in block  at /home/david/git/PDF-Content-raku/lib/PDF/Content/Ops.rakumod (PDF::Content::Ops) line 1039
  .ClosePath();
Unexpected operation 'S' (Stroke) used in Page context, following 'h' (ClosePath)
  in block  at /home/david/git/PDF-Content-raku/lib/PDF/Content/Ops.rakumod (PDF::Content::Ops) line 1039
  .Stroke();
.Restore();

[tbrowder]

On Thu, Sep 5, 2024 at 15:18 David Warring @.***> wrote:

Also, the running the script pdf-content-dump.raku --raku my.pdf might help with tracking done the error. For example:

...

Thanks very much, David!

Best regards,

-Tom

[tbrowder]

Thanks to your 'pdf-content-dump.raku. script I found the problem.

I had used ".Fill; .Stroke" instead of ".FillStroke" and, by using the correct alias, the warnings disappeared.

[tbrowder]

Closing this.