Relative leveloffset for nested includes not working properly anymore

[Bellamonte]

Hi,

starting at latest with version 0.28.0, a relative leveloffset doesn't produce the right section/heading level structure anymore in Confluence, when nesting includes: The next sub-section after the include inside an include with relative leveloffset gets pushed up one level in the structure in the output.

Example to reproduce: index.adoc:

= Test Document
:toclevels: 6
:numbered:
:sectnumlevels: 6
:toc: macro

[preface]
== Table of Contents
toc::[]

== Chapter 1

=== Sub-Chapter 1.1

=== Sub-Chapter 1.2

=== Sub-Chapter 1.3

include::sub/test2.adoc[leveloffset=+1]

== Chapter 3

sub/test2.adoc:

= Chapter 2 (as include)

== Sub-Chapter 2.1

include::test2_2.adoc[leveloffset=+1]

// here the structure breaks:
== Sub-Chapter 2.3

sub/test2_2.adoc:

= Sub-Chapter 2.2 (as include inside include)

Hope, you can fix this soon.

Cheers, Michelle

[cstettler]

Hi @Bellamonte, thank you for your issue report. However, I was not able to reproduce the issue based on your example sources. Both in Confluence Server as well as in Confluence Cloud, I get the correct section nesting:

Confluence Server (6.0.5)

Confluence Server

What exact version of the Confluence Publisher are you using? And are you publishing via Maven or via the Docker image? Thank you for your input!

[Bellamonte]

Hi @cstettler ,

thanks for replying.

My environment:

• Maven: 3.9.9
• Confluence Publisher: 0.29.0
• Confluence: Server / 9.2.5

I just put this example up plainly and it generates the correct output, same as for you.

I then started reintegrating stuff and seem to have found some clue: If I add a AsciidoctorJ extension based on AsciidoctorJ 3.0.0 as dependency, which has a registered Preprocessor, where the input PreprocessorReader of process method is read from via readLines(), it produces the wrong output again. I even removed the stuff my real preprocessor does and just returned a newReader() with just the same lines previously read, so it isn't something from what my Preprocessor normally is doing as this doesn't come into effect anymore:

package com.oneandone.bs.comet.asciidoctorj.confluence.extension.processor;

import org.asciidoctor.ast.Document;
import org.asciidoctor.extension.Preprocessor;
import org.asciidoctor.extension.PreprocessorReader;
import org.asciidoctor.extension.Reader;

import java.util.List;

public class TextDecorationPreprocessor extends Preprocessor {

    @Override
    public Reader process(Document document, PreprocessorReader reader) {
        List<String> lines = reader.readLines();

        for (String line: lines) {
            System.out.println(line);
        }

        return newReader(lines);
    }
}

I also debugged the lines from the readLine() of the input PreprocessorReader and found something strange:

= Test Document
:toclevels: 6
:numbered:
:sectnumlevels: 6
:toc: macro

[preface]
== Table of Contents
toc::[]

== Chapter 1

=== Sub-Chapter 1.1

=== Sub-Chapter 1.2

=== Sub-Chapter 1.3

:leveloffset: +1

= Chapter 2 (as include)

== Sub-Chapter 2.1

:leveloffset: +1

= Sub-Chapter 2.2 (as include inside include)

:leveloffset!:

// here the structure breaks:
== Sub-Chapter 2.3

:leveloffset!:

== Chapter 3

The :leveloffset!: after the Sub-Chapter 2.2 produces a top-most headline in Confluence then for Sub-Chapter 2.3 instead of a second-level one. This seems not to be the case though, if I just return the input Preprocessor in method process(). So this seems to be some side-effect only when readLines() is called on the input Proprocessor...

Hope that helps in analysis of the issue.

Cheers, Michelle

[cstettler]

Hi @Bellamonte, thank you for the additional details in the issue your are noticing. Before digging into the details and in order to understand, what is your use case for registering an AsciidoctorJ extensions to Confluence Publisher?

Regarding the pre-processor: I am able to reproduce the issue in an test, but I assume that this is probably more an AsciidoctorJ-related issue than an issue of Confluence Publisher. According to the documentation, readLines() is processing each line and as a consequence, invokes pre-processors. I suspect that this is causing a side effect, maybe because some context is not yet correctly set up. But this is pure speculation. Do you maybe want to check back on the AsciidoctorJ discussion list?