On 11 January 2013 18:50, Stuart Rackham <[email protected]> wrote:
>
>
> On 31/12/12 14:58, Stuart Rackham wrote:
>>
>>
>> On 10/10/12 11:49, Lex Trotman wrote:
>>>
>>>
>>> On 10 October 2012 04:34, Jens Getreu <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> I observed the following behavior:
>>>
>>> 1. Without :data-uri: directive: Paths in subdocuments to images
>>> are relative to the location of the main document.
>>> 2. With :data-uri: Paths in subdocuments to images are relative to
>>> the location of the subdocument.
>>>
>>> I usually use the 2. because my subdocuments are independent
>>> projects with separate resources. Unfortunately not all backends
>>> implement the 2. correctly yet.
>>> For example the html4 and odt backends do not therefore my projects
>>> do not compile with these backends.
>>>
>>>
>>> The ODT backend is a separate project, please file an issue on its site.
>>>
>>> Data-uri is not supported by HTML, only xhtml and html5.
>>>
>>> They should all follow type two, but there is a bug(s).
>>>
>>> @Stuart, documentation says images are relative to the referring
>>> document. Data-uri correctly uses {indir}/{imagesdir}/{target} but non
>>> data-uri uses {imagesdir}/{target} which makes them relative to the
>>> *working* directory (if {imagesdir} is not absolute), not the document
>>> directory. It is therefore wrong if for example the document is an
>>> included document from another directory, or asciidoc wasn't run in the
>>> document directory.
>>>
>>> Documentation doesn't mention absolute being accepted, but I'll bet
>>> there are lots of documents that depend on that :( so it isn't just as
>>> simple as sticking an {indir={outdir}} on the front for non-datauri I
>>> don't think.
>>
>> This would probably work:
>>
>> {eval:os.path.join(r"{indir={outdir}}",r"{imagesdir=}",r"{target}")}
>>
>> because if {imagesdir=} is absolute os.path.join() will override the
>> preceding {indir={outdir}}
>>
>> But is will break documents out there that rely on this undocumented quirk?
>>
>> Cheers, Stuart
>>
>>
>
> My suggestion will not work, you shouldn't use absolute paths in links
> -- they won't be served by a Web server.
True, though they will work locally with a browser. But ok, absolute
paths should not be used and can be ignored.
>
> The problem comes down to the fact that the link is relative to the root
> document and not the included file. There's no relative version of
> {indir} (relative to {docdir}) so the only way I can see would be to
> synthesize a relative path.
>
> Instead of:
>
> {imagesdir=}{imagesdir?/}{target}
>
> use:
>
> {imagesdir=}{imagesdir?/}{eval:os.path.relpath(r"{docdir={outdir}}",r"{indir={outdir}}")}/{target}
If I understand it correctly the problem was that the directory that
the input image file needed to be in was different depending on the
setting of the data-uri attribute.
To quote Jens:
1. Without :data-uri: directive: Paths in subdocuments to images are
relative to the location of the main document.
2. With :data-uri: Paths in subdocuments to images are relative to the
location of the subdocument.
So the same source tree cannot be used for both embedded and linked
output since images for the subdocuments need to be in different
places. (Ok, on *ix you can use links, but its kinda messy, and won't
work on Windows).
>
> But it's not the complete answer because the relative path can only be
> calculated if the the two locations lie on a common path.
Or maybe just make the required document *source* locations the same
in both cases. I suggest always relative to the *including* document
so subdocuments can be processed independently as well as when
included. The generated link should be relative to {outdir} so its
relative to the generated HTML file as required.
Cheers
Lex
>
> I think the best solution would be to leave the current (incorrectly
> documented and sub-optimal) behavior as it is and change the
> documentation to reflect it.
>
>
> Cheers, Stuart
>
>
>>>
>>> Cheers
>>> Lex
>>>
>>>
>>>
>>> The :data-uri: directive is meant to embed media HTML5. So the
>>> described behavior is just a side effect? Is it possible to control
>>> how paths are interpreted by other means then :data-uri: ?
>>>
>>> If not, there should be a directive doing so.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "asciidoc" group.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msg/asciidoc/-/uIpKdckPkwYJ.
>>> To post to this group, send email to [email protected]
>>> <mailto:[email protected]>.
>>> To unsubscribe from this group, send email to
>>> [email protected]
>>> <mailto:asciidoc%[email protected]>.
>>> For more options, visit this group at
>>> http://groups.google.com/group/asciidoc?hl=en.
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "asciidoc" group.
>>> To post to this group, send email to [email protected].
>>> To unsubscribe from this group, send email to
>>> [email protected].
>>> For more options, visit this group at
>>> http://groups.google.com/group/asciidoc?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "asciidoc" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/asciidoc?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"asciidoc" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/asciidoc?hl=en.
