Workaround to resolve imagesdir when using includes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Workaround to resolve imagesdir when using includes

ch007m
Hi,

When we have a parent/children directories structure and where we use include:: macro in the parent file to include a file defined in a children directory, the images are not included (not retrieved) in the HTML generated. Asciidoctor will try to find the images directory relative to the parent directory. Is there a workaround as adding imagesdir: does not help here  ?

parent directory
  all_slides.index --> include::child1/eleonor.ad & include::child2/pauline.ad
  child1
    images
      a_picture.png    
    eleonor.ad  --> image::images/a_picture.png
  child2
    images
     b_picture.png
    pauline.ad -->  image::images/b_picture.png

HTML generated

<body class="article">
<div id="header">
</div>
<div id="content">
<div class="sect1">
<h2 id="_test">Test</h2>
<div class="sectionbody">

</div>
</div>
<div class="sect1">
<h2 id="_eleonor">Eleonor</h2>
<div class="sectionbody">
<div class="imageblock">
<div class="content">
<img src="images/a_picture.png" alt="a picture">
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_pauline">Pauline</h2>
<div class="sectionbody">
<div class="imageblock">
<div class="content">
<img src="images/a_picture.png" alt="a picture">
</div>
</div>
</div>
</div>
</div>
<div id="footer">
<div id="footer-text">
Last updated 2014-02-19 15:07:23 CET
</div>
</div>
</body>

Regards,

Charles
 
Charles Moulliard
Apache Committer / Technologist Evangelist / Blogger / MiddleWare Specialist
Twitter : @cmoulliard
Reply | Threaded
Open this post in threaded view
|

Re: Workaround to resolve imagesdir when using includes

LightGuardjp
You could try setting basedir in the documents and resolving relative to that base directory. 

Sent from Mailbox for iPhone


On Wed, Feb 19, 2014 at 7:17 AM, ch007m [via Asciidoctor :: Discussion] <[hidden email]> wrote:

Hi,

When we have a parent/children directories structure and where we use include:: macro in the parent file to include a file defined in a children directory, the images are not included (not retrieved) in the HTML generated. Asciidoctor will try to find the images directory relative to the parent directory. Is there a workaround as adding imagesdir: does not help here  ?

parent directory
  all_slides.index --> include::child1/eleonor.ad & include::child2/pauline.ad
  child1
    images
      a_picture.png    
    eleonor.ad  --> image::images/a_picture.png
  child2
    images
     b_picture.png
    pauline.ad -->  image::images/b_picture.png

HTML generated

<body class="article">
<div id="header">
</div>
<div id="content">
<div class="sect1">
<h2 id="_test">Test</h2>
<div class="sectionbody">

</div>
</div>
<div class="sect1">
<h2 id="_eleonor">Eleonor</h2>
<div class="sectionbody">
<div class="imageblock">
<div class="content">
<img src="images/a_picture.png" alt="a picture">
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_pauline">Pauline</h2>
<div class="sectionbody">
<div class="imageblock">
<div class="content">
<img src="images/a_picture.png" alt="a picture">
</div>
</div>
</div>
</div>
</div>
<div id="footer">
<div id="footer-text">
Last updated 2014-02-19 15:07:23 CET
</div>
</div>
</body>

Regards,

Charles
 
Charles Moulliard
Apache Committer / Technologist Evangelist / Blogger / MiddleWare Specialist
Twitter : @cmoulliard



If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Workaround-to-resolve-imagesdir-when-using-includes-tp1517.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: Workaround to resolve imagesdir when using includes

getreu
In reply to this post by ch007m
The subject is also discussed here:

https://github.com/asciidoctor/asciidoctor/issues/894
Reply | Threaded
Open this post in threaded view
|

Re: Workaround to resolve imagesdir when using includes

mojavelinux
Administrator

Or you could just write an include processor extension, then you can pretty much get whatever behavior you want.

In fact, I'm beginning to realize that the fact that we have the include processor gets us out of having to land a solution for this challenge before 1.5.0.

-Dan

On Feb 24, 2014 7:39 AM, "getreu [via Asciidoctor :: Discussion]" <[hidden email]> wrote:
The subject is also discussed here:

https://github.com/asciidoctor/asciidoctor/issues/894



If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Workaround-to-resolve-imagesdir-when-using-includes-tp1517p1534.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: Workaround to resolve imagesdir when using includes

mojavelinux
Administrator
In reply to this post by getreu

The long term solution to this problem, IMO, is that we need to have a subdocument block macro (which could also be an extension, btw).

Because include is a preprocessor directive, it can be used in places where subdocument behavior makes no sense (such as in a listing block). It's just not the appropriate hook for subdocuments. We need something dedicated for that purpose that has awareness of the context & document tree. I think this makes the requirement way simpler to meet.

-Dan

On Feb 24, 2014 7:39 AM, "getreu [via Asciidoctor :: Discussion]" <[hidden email]> wrote:
The subject is also discussed here:

https://github.com/asciidoctor/asciidoctor/issues/894



If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Workaround-to-resolve-imagesdir-when-using-includes-tp1517p1534.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: Workaround to resolve imagesdir when using includes

getreu
Concerning the requirements that new "includedocument" block macro should meet I'd like to come back to my initial considerations in hope that you still share them (see also https://github.com/asciidoctor/asciidoctor/issues/894):

1) A subdocument is an self-sufficient entity. It has it's own resources images etc. and can be processed individually. It can be packed and deployed everywhere in the source tree.
2) A master document includes subdocuments. If all subdocuments compile without error the master does so too.
3) The only property distinguishing a master and a subdocument is that the first includes the second. Thus it is possible that they exchange roles: the master can become subdocument and the subdocument can become master without changing any relative paths.




Jens
PS: I post this at several places

PPS: In reply to: http://discuss.asciidoctor.org/Workaround-to-resolve-imagesdir-when-using-includes-td1517.html

As I understand you do not want to modify the behaviour of include and rather introduce a new "includedocument" command. In deed there are some good technical arguments not to do so: A preprocessor directive should do nothing else then sourcing another file.

Still from the user point of view we want to distinguish 2 cases:
"include" :::                  including a file (which is a resource of a document, like pictures, source code
                                     etc.) without changing any variables.
"includedocument" :::  including another (sub-)document which has its own resources, it's own
                                    pictures etc. It needs to have inter alia a modified root directory.
                                    Access to the parents root directory would also be useful.
 
Distinguishing a) and b) is trivial:
a sourced subdocument has a title ("= Title") this is case b). A sourced file without title is case a).

So I still do not see the benefit of introducing a new command for b) (although I could happily live with it).