Problem with quotes on generated img elements

[Richard-Linsdale]

markdown of form

![word word word](image.jpg)

![oneword](image.jpg)

generates html with incorrect quotes (too many in trailing position of alt attribute)

<p><img src="image.jpg" alt="word word word""/></p><p><img src="image.jpg" alt="oneword""/></p>

[Richard-Linsdale]

Just looked at pegdown issues and it seems this is a bug which was introduced in 1.4.2, but is now fixed

see pegdown issue 130 -- Invalid HTML when serializing images

looks like you will have to pull a later version of pegdown

[madflow]

Hi,

yep - there is a regression in the latest development code! There is a pull request for this in pegdown (sirthias/pegdown#133) which has not been merged yet.

We always use the latest packaged release of pegdown - so we will be patient and wait for the next release with this pull request merged.

If you want to hack on the latest development code of netbeans-markdown - things can break like this from time to time.

If you would simply like Markdown Support in NetBeans - The pre-compiled releases are your best bet:

https://github.com/madflow/flow-netbeans-markdown/releases

Thanks for your interest in this plugin!

[madflow]

Okay - It turns out we override the image tag rendering after all in the plugin...

I tested the fix with this commit 88aaafc and it looks better (to say the least),

I witnessed some occasional NullPointerException (not sure if it is related).

Maybe you can have a quick test on your side?

[Richard-Linsdale]

Using your latest N8 branch my markdown generation still failed with the same problem code generated.

your commit made a minor typographic change to the existing printImageTag (space added between closing quote and closing ">") and you introduced an additional printImageTag method with an alternative signature (which was defined with an @OverRide directive.)

I ran my simple test case (see the info in the first posting for this issue) in debug mode, and neither printImageTag methods where called when the html was generated. I have to assume that the pegdown method for image tag creation is used and hence the bug in 1.4.2 is being seen in your plug-in's html generation.

Hope this is helpful.

/Richard

[madflow]

Thanks for the test. Yes it helped. I believe I was investigating in the wrong place. You wrote "generates html" and I thought you meant the html preview.

The preview did call the newly created method - the export did not. I took a second shot at the issue by just adapting the "preview" code. With my setup (NetBeans 8, JDK 8, Linux) the export now produces a valid image tag - but it is a hack.

[Richard-Linsdale]

The quoting problem seems to be resolved - however the src attribute is expanded into an absolute file path and so the resulting code is not transportable to servers etc. Given that the attribute value is defined in the md text (can be either a relative or absolute file path) I would have hoped that the attribute value would be copied as-is into the resulting img element.

![word word word](image.jpg)

results in

<img src="file:/home/richard/GitHubProjects/debugging/image.jpg" alt="word word word" />

where as I would have hoped it would result in

<img src="image.jpg" alt="word word word" />

tested on the same environment as you are using ie NetBeans 8, JDK 8, Linux.

[madflow]

I reverted the premature fix from above and introduced a custom HTML export/generation class for the export feature.

The last commit f3cd809 fixes the issues above. I will do some more testing in the next couple of days if I have missed something.

[Richard-Linsdale]

Looks good for "Generate HTML".
"View HTML" still generates absolute file paths - but that's not a problem as view will work and does not create long-lived output. However just to be tidy, it would be good if both View and Generate created the same output.

[stengerh]

It might be tidy but it comes with other drawbacks. The reason I introduced absolute image URLs in the preview HTML was to enable the correct display of images. Since the preview HTML gets written to a temporary file relative paths wouldn't work. I also didn't want to write the preview HTML to the same directory as the Markdown file as that might have broken existing workflows. The assumption here is that (most) people use the preview functionality as a visual preview and not as a preview of the HTML source code.

[Richard-Linsdale]

good point - I accept that further changes to "view HTML" is not good. So commit f3cd809 seems to be the fix for this issue (unless someone notices something that I haven't).