Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Indentation of linenumber for (very) long code blocks #402

Closed
GregorOphey opened this issue Feb 19, 2016 · 1 comment
Closed

Indentation of linenumber for (very) long code blocks #402

GregorOphey opened this issue Feb 19, 2016 · 1 comment
Assignees
Labels

Comments

@GregorOphey
Copy link

When turning on line numbers for code blocks with imported files, the lines are indented in the generated pdf output. The amount of indentation seems to increase with the length of the included code.

I understand that indentation is indeed required for right-alingning the line numbers. However, if the number of lines of code goes into the hundreds or thousands, the calculation for the indentation seems to be buggy, because the level of indentiation is far too big. With 1000 code lines the output has additional blank lines ...

The resulting pdf is attached as
line-num-issue.pdf

You can reproduce it by following the steps outlined below

Here is a sample .adoc that includes xml code files of increasing length w/o and with line numbers:

:source-highlighter: rouge
:source-dir: ./src/


[source,xml]
----
include::{source-dir}test10.xml[]
----

[source,xml,linenums]
----
include::{source-dir}test10.xml[]
----

[source,xml]
----
include::{source-dir}test100.xml[]
----

[source,xml,linenums]
----
include::{source-dir}test100.xml[]
----

[source,xml]
----
include::{source-dir}test1000.xml[]
----

[source,xml,linenums]
----
include::{source-dir}test1000.xml[]
----

And here's some code to generate the xml files to include:

File.open("test#{ARGV.first}.xml", "w") do |xmlFile|
  xmlFile.puts '<root>' ; 
  (1..ARGV.first.to_i).each { |i| xmlFile.puts " <node>#{i}</node>"; };
  xmlFile.puts '</root>';
end

Save that to a file and call it with:

ruby <file-name-chosen> 10

to generated a test10.xml containing the following xml code:

<root>
 <node>1</node>
 <node>2</node>
 <node>3</node>
 <node>4</node>
 <node>5</node>
 <node>6</node>
 <node>7</node>
 <node>8</node>
 <node>9</node>
 <node>10</node>
</root>

You can generate the other two files with

ruby <file-name-chosen> 100

and

ruby <file-name-chosen> 1000

respectively.

Test data needs to be in a ./src folder

Then generate the document as follows:

asciidoctor -r asciidoctor-pdf -b pdf line-num-issue.adoc

Note on performance:

Also when you increase the number of nodes even further, say 10000, and include the resulting file with line numbers, you will notice that generation of the pdf takes very long ... and indeed will complete only when increasing the available stack/heap for the jvm.

I used:

alias jruby='jruby -J-Xms2048m -J-Xmx4096m'

for my concrete use case where I included a generated xsd of 16000 lines. That took like 1.5 hrs to generate the pdf and the listing was faily useless due to excessive indentation leading to multiple blank lines ...

@mojavelinux mojavelinux added the bug label Aug 8, 2016
@mojavelinux mojavelinux added this to the v1.5.0.alpha.13 milestone Aug 8, 2016
@mojavelinux mojavelinux self-assigned this Aug 8, 2016
@mojavelinux
Copy link
Member

How right you are. I was using the following to determine the number of digits in the largest line number:

linenum_w = (linenum / 10) + 1

Obviously, that's not going to work :/

Here's the Ruby way of doing it:

linenum_w = linenum.to_s.size

(That's effective the same as taking the log base 10, but much faster).

As for the performance, there's not much we can do. Prawn doesn't give us the proper toolset for page overflow, so we have to do a lot of work to layout a source block, including writing to a scratch document. The line numbers add about a 20% overhead, but the bulk of the time is in the handling of the source block itself.

The reason the line numbers add such a big overhead is because we have to go through the code token by token to find all the endlines, then rebuild the fragments to add the line numbers in front. This could be made more efficient if Rouge weaved in the line numbers for us or gave us the tokens organized by line already.

mojavelinux added a commit to mojavelinux/asciidoctor-pdf that referenced this issue Aug 8, 2016
- correctly calculate width of largest line number
fapdash pushed a commit to vogellacompany/asciidoctor-pdf that referenced this issue Dec 13, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants