image: versus image:: and some problems in tables

[DocEvaluator]

Hello, I have encountered some problems with embedding images. The following adoc file shall highlight the problems:

== image:: vs image: and spaces in name

.One, will not work because of spaces
image::thank you.jpg[]

.Two, this works and generates 'Figure'
image::cp3.png[]


.Three, works, but will not generate 'Figure'
image:thank you.jpg[]


.Four, works as well, but will not generate 'Figure'
image:cp3.png[]




== Table stuff

And now some errors with the generated numbers of the Figures. I only use "image::" here and %20 for masking the spaces:

.Outside the table
image::thank%20you.jpg[]

[cols=","]
|====
a|
.Inside the table
image::thank%20you.jpg[]

a|
.Also inside, same number!
image::cp3.png[]
|====


Next table:

[cols=","]
|====
a|
.Inside the table
image::thank%20you.jpg[]

a|
.Also inside, same number!
image::cp3.png[]
|====

.Outside again
image::thank%20you.jpg[]

.and again
image::thank%20you.jpg[]

So, first thing I see is, that I can still use image: (with one colon). Is this the legacy Asciidoc syntax? Well, that's okay, but there's different behaviour with treating spaces in file names.
image:: will not recognize this (i.e. it does not produce a rendering problem, but it seems that command to embed an image  isn't regonized at all). It took me really long to find the %20 solution - unfortunately this wasn't documented and for me this solution didn't come naturally (although I know it from the web context of course).

Next thing is, that the numbers of the generated "Figure" description inside tables will not increase if you are generating .html output (tested Chrome plugin and the standard ruby stuff). For the PDF output it worked correctly.

Is it okay to post the errors/glitches here or is there some other way?
Because I think the documentation should be extended in some ways: is there a way to participate on the documentation which is found on the asciidoctor.org page?

Thanks in advance and thanks for your awesome Asciidoc(tor) work

[mojavelinux]

On Wed, Nov 16, 2016 at 6:40 AM, DocEvaluator [via Asciidoctor :: Discussion] <[hidden email]> wrote:

So, first thing I see is, that I can still use image: (with one colon). Is this the legacy Asciidoc syntax? Well, that's okay, but there's different behaviour with treating spaces in file names.

A single colon is an inline image (in the line of text, such as a paragraph). A double colon is a block image (aka figure). This distinction between inline and block macros is universal in AsciiDoc.

When it comes to images, you almost always want to use a block image.

-Dan

--

[mojavelinux]

On Wed, Nov 16, 2016 at 6:40 AM, DocEvaluator [via Asciidoctor :: Discussion] <[hidden email]> wrote:

Is it okay to post the errors/glitches here or is there some other way?

You can post here if you aren't sure about whether you've found a bug. If you are sure you've found a bug, then it's best to create an issue in the the issue tracker at https://github.com/asciidoctor/asciidoctor/issues. We do ask that you browser for existing issues first.

 

Because I think the documentation should be extended in some ways: is there a way to participate on the documentation which is found on the asciidoctor.org page?

There's an issue tracker for the website / documentation. See https://github.com/asciidoctor/asciidoctor.org/issues.

-Dan

--

[mojavelinux]

On Wed, Nov 16, 2016 at 6:40 AM, DocEvaluator [via Asciidoctor :: Discussion] <[hidden email]> wrote:

[cols=","]

Technically this is invalid syntax. It should be written as:

[cols=2*]

or

[cols="1,1"]

--

[mojavelinux]

Another way to write a path with a space is to use the space attribute:

image::thank{sp}you.jpg[]

However, I can't recommend strongly enough to avoid using spaces in filenames. It's generally considered to be a bad practice because it frequently confuses programs that use spaces as a delimiter between parameters.

-Dan

On Wed, Nov 16, 2016 at 2:57 PM, Dan Allen <[hidden email]> wrote:

On Wed, Nov 16, 2016 at 6:40 AM, DocEvaluator [via Asciidoctor :: Discussion] <[hidden email]> wrote:

Is it okay to post the errors/glitches here or is there some other way?

You can post here if you aren't sure about whether you've found a bug. If you are sure you've found a bug, then it's best to create an issue in the the issue tracker at https://github.com/asciidoctor/asciidoctor/issues. We do ask that you browser for existing issues first.

 

Because I think the documentation should be extended in some ways: is there a way to participate on the documentation which is found on the asciidoctor.org page?

There's an issue tracker for the website / documentation. See https://github.com/asciidoctor/asciidoctor.org/issues.

-Dan

--

... [show rest of quote]

--

[mojavelinux]

On Wed, Nov 16, 2016 at 6:40 AM, DocEvaluator [via Asciidoctor :: Discussion] <[hidden email]> wrote:

Next thing is, that the numbers of the generated "Figure" description inside tables will not increase if you are generating .html output (tested Chrome plugin and the standard ruby stuff).

That does seem to be a bug. Thanks for catching it. Would you be willing to submit an issue describing the problem?

Cheers,

-Dan 

--

[DocEvaluator]

Thanks for all your answers, they were really helpful!

Of course I try to avoid spaces in any filenames during development, but sometimes you just have to stick with the input from third-party deliveries ;-)

I will file the "table number bug" for html within the next days and hopefully some documentation improvements/change requests, too.

[DocEvaluator]

mojavelinux wrote

> So, first thing I see is, that I can still use image: (with one colon). Is
> this the legacy Asciidoc syntax? Well, that's okay, but there's different
> behaviour with treating spaces in file names.


A single colon is an inline image (in the line of text, such as a
paragraph). A double colon is a block image (aka figure). This distinction
between inline and block macros is universal in AsciiDoc.

Okay, but what about the different treatment of spaces? Despite the fact that I try to avoid them and know how to mask them, an inline image can cope with them, a block image does not.
Shall I file a bug for the block image handling of spaces or shall I file a documentation improvement?

[mojavelinux]

On Thu, Nov 17, 2016 at 12:47 AM, DocEvaluator [via Asciidoctor :: Discussion] <[hidden email]> wrote:

Okay, but what about the different treatment of spaces? Despite the fact that I try to avoid them and know how to mask them, an inline image can cope with them, a block image does not.
Shall I file a bug for the block image handling of spaces or shall I file a documentation improvement?

It seems pretty reasonable to me to allow spaces in the target of a block image. I think the only reason it isn't allowed is because it wasn't implemented in AsciiDoc Python. However, we can move beyond that limitation. So yes, we'll need an issue for that enhancement as well.

Cheers,

-Dan

--

[DocEvaluator]

mojavelinux wrote

 So yes, we'll need an issue for that enhancement as well.

Okay, done! Because I am quite new to git, please excuse any Contribution violation I may have committed.

Best regards,
Eike

[mojavelinux]

Thanks Eike!

-Dan

On Mon, Nov 21, 2016 at 6:16 AM, DocEvaluator [via Asciidoctor :: Discussion] <[hidden email]> wrote:

mojavelinux wrote

 So yes, we'll need an issue for that enhancement as well.

Okay, done! Because I am quite new to git, please excuse any Contribution violation I may have committed.

Best regards,
Eike

---

If you reply to this email, your message will be added to the discussion below:

http://discuss.asciidoctor.org/image-versus-image-and-some-problems-in-tables-tp5105p5127.html

To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML

--