Currently, we're still using the defaults from ASCIIdoctor to generate PDF versions. We already made several changes to make it flow much better on ebook versions, but this had the side effect of (by removing the use of tables) already made PDF versions taking more pages. Maybe near doubling the number of pages.
Now, we have another problem: the ideal would be to align PDF versions in more columns, but this is not easier to accomplish with AaciiDoctor. In fact the main developer argue this feature is not at all very requested. However, even if we do offer ebook versions, people may at first use PDF versions on mobile. And by creating two (maybe three) columns, we would make the experience bad.
Approach to be tested
Let's just make even the PDF version an A5 instead of A4 size. We both fix the usability issue on mobile (for people using PDF I stead of e-book) and people using computer can use the sidebar to access the Table of Contents.
About really printed versions on paper.
One somewhat advantage of go A5 is, without too much explanation, someone willing to print on paper may have ideas to print... Two per page. This would make a 800 page A5 group of dictionaries fit on 400 pages on paper.
Actually on our tests, it is somewhat viable to even fit 4 of this new version on a typical A4, and the final font size would not be far different than an average dictionary. That would make the 800 pages down to 200 pages (or 100 if both sides).
Like I said, most people already use mobile phones. But even those who need paper could still decide how much paper they would want for a version.
Other optimizations
We may need to make some further optimizations related to font size and space. For example we do use space on description lists to give an idea of the level of the information. But even on the Ebook versions, some readers remove such spaces entirely. This may be one reason we have to resort, even om PDF versions (to not need to have more than one .adoc) add some visual character to indicate level of nesting of the information. Maybe this will be archived by adding numeric prefix or alphabetic numbers (to differentiate from the coding numbers).
Naturally, versions not using Latin could resort to other strategies on paper. If we use "I, II, III, IV, V, ..." this should not be replicated in any other dictionary which does not use the Latin alphabet.
Currently, we're still using the defaults from ASCIIdoctor to generate PDF versions. We already made several changes to make it flow much better on ebook versions, but this had the side effect of (by removing the use of tables) already made PDF versions taking more pages. Maybe near doubling the number of pages.
Now, we have another problem: the ideal would be to align PDF versions in more columns, but this is not easier to accomplish with AaciiDoctor. In fact the main developer argue this feature is not at all very requested. However, even if we do offer ebook versions, people may at first use PDF versions on mobile. And by creating two (maybe three) columns, we would make the experience bad.
Approach to be tested
Let's just make even the PDF version an A5 instead of A4 size. We both fix the usability issue on mobile (for people using PDF I stead of e-book) and people using computer can use the sidebar to access the Table of Contents.
About really printed versions on paper.
One somewhat advantage of go A5 is, without too much explanation, someone willing to print on paper may have ideas to print... Two per page. This would make a 800 page A5 group of dictionaries fit on 400 pages on paper.
Actually on our tests, it is somewhat viable to even fit 4 of this new version on a typical A4, and the final font size would not be far different than an average dictionary. That would make the 800 pages down to 200 pages (or 100 if both sides).
Like I said, most people already use mobile phones. But even those who need paper could still decide how much paper they would want for a version.
Other optimizations
We may need to make some further optimizations related to font size and space. For example we do use space on description lists to give an idea of the level of the information. But even on the Ebook versions, some readers remove such spaces entirely. This may be one reason we have to resort, even om PDF versions (to not need to have more than one .adoc) add some visual character to indicate level of nesting of the information. Maybe this will be archived by adding numeric prefix or alphabetic numbers (to differentiate from the coding numbers).
Naturally, versions not using Latin could resort to other strategies on paper. If we use "I, II, III, IV, V, ..." this should not be replicated in any other dictionary which does not use the Latin alphabet.