Open iT-Boyer opened 3 years ago
<?xml version="1.0" encoding="UTF-8" standalone="no"?><svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" contentScriptType="application/ecmascript" contentStyleType="text/css" height="321px" preserveAspectRatio="none" style="width:792px;height:321px;background:#FFFFFF;" version="1.1" viewBox="0 0 792 321" width="792px" zoomAndPan="magnify"><defs/><g><rect fill="#DDDDDD" height="287.0469" rx="5" ry="5" style="stroke:#000000;stroke-width:1.0;" width="768" x="8" y="18"/><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="400" x="14" y="35.9951">The plugin you are using seems to generated a bad URL.</text><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="301" x="14" y="52.292">This URL does not look like DEFLATE data.</text><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="368" x="14" y="68.5889">It looks like your plugin is using HUFFMAN encoding.</text><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="0" x="18" y="84.8857"/><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="670" x="14" y="101.1826">This means you have now to add an header ~1 to your data. For example, you have to change:</text><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="569" x="14" y="117.4795">http://www.plantuml.com/plantuml/png/-base64-QHN0YXJ0dW1sCmlmIChjb2...</text><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="16" x="14" y="133.7764">to</text><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="589" x="14" y="150.0732">http://www.plantuml.com/plantuml/png/~1-base64-QHN0YXJ0dW1sCmlmIChjb2...</text><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="0" x="18" y="166.3701"/><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="139" x="14" y="182.667">It will work this way</text><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="437" x="14" y="198.9639">You may contact the PlantUML team at plantuml@gmail.com</text><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="756" x="14" y="215.2607">But you should also probably contact the plugin authors you are currently using and send them this image</text><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="0" x="18" y="231.5576"/><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="235" x="14" y="247.8545">For the record, here is your data:</text><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="0" x="18" y="264.1514"/><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="676" x="14" y="280.4482">-base64-QHN0YXJ0dW1sCmlmIChjb2xvcj8pIGlzICg8Y29sb3I6cmVkPnJlZCkgdGhlbgo6cHJpbnQg</text><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="461" x="14" y="296.7451">cmVkOwplbHNlCjpwcmludCBub3QgcmVkOwpAZW5kdW1sCg==</text><!--MD5=[4046266bd573de7cefaabdd27b96817e]
@startuml
legend
The plugin you are using seems to generated a bad URL.
This URL does not look like DEFLATE data.
It looks like your plugin is using HUFFMAN encoding.
This means you have now to add an header ~1 to your data. For example, you have to change:
http://www.plantuml.com/plantuml/png/-base64-QHN0YXJ0dW1sCmlmIChjb2...
to
http://www.plantuml.com/plantuml/png/~1-base64-QHN0YXJ0dW1sCmlmIChjb2...
It will work this way
You may contact the PlantUML team at plantuml@gmail.com
But you should also probably contact the plugin authors you are currently using and send them this image
For the record, here is your data:
-base64-QHN0YXJ0dW1sCmlmIChjb2xvcj8pIGlzICg8Y29sb3I6cmVkPnJlZCkgdGhlbgo6cHJpbnQg
cmVkOwplbHNlCjpwcmludCBub3QgcmVkOwpAZW5kdW1sCg==
endlegend
@enduml
PlantUML version 1.2021.13beta5(Unknown compile time)
(GPL source distribution)
Java Runtime: Java(TM) SE Runtime Environment
JVM: Java HotSpot(TM) 64-Bit Server VM
Default Encoding: UTF-8
Language: en
Country: US
--></g></svg>
Here the PlantUML team gives a more detailed explanation why this happens.
@kasimirmoilanen do you find that prefixing data with ~1
header as suggested above, fixes the problem?
I just tried that (by patching line 432 in plantuml-mode.el), but I still get error saying:
This URL does not look like HUFFMAN data
@natrys I tried this as a quick fix, but I also still get the error. I just changed plantuml-default-exec-mode to jar as specified in the readme, I think that or executable mode are better anyway as you don't need to connect to external servers. And fair to note that yes, I did remember to compile the patched plantuml-mode.el, it's a bit weird that the problem persists.
@kasimirmoilanen Yeah you are right. I was looking to avoid java things in all my machines, but I suppose it is what it is.
Anyway, looking at the elisp function, it appears that the function was merely doing base64 encoding, without performing the compression (hoffman or deflate) required before that, so no wonder it doesn't work.
As for fixing the issue, Emacs sadly doesn't have compression primitives like zlib or brotli, which appears to be the server's recommendation now. Emacs actually builds with zlib, but the FFI only exposes decompression. I found that someone sent patch to add compression too in mailing list, but somewhat true to form it got lost in discussion without actually getting merged:
https://lists.gnu.org/r/emacs-devel/2020-03/msg00802.html
We could just shell out to gzip I guess. But as I try this, it appears that the bigger problem is that the server seems to expect a modified base64 encoding for legacy reasons:
https://plantuml.com/en/text-encoding
So off the shelf base64 from coreutils or base64-encode-string
shouldn't have been able to work anyway.
That page also lists that now API also accepts hex encoding, which is finally something that's doable in pure elisp. This of course increases size 2x from plaintext, which is kind of terrible. But for now I don't really care:
(defun hex-encode (str)
(string-join (mapcar (lambda (c) (format "%02x" c)) str)))
(defun plantuml-server-encode-url (string)
"Encode the string STRING into a URL suitable for PlantUML server interactions."
(let* ((encoded-string (hex-encode string)))
(concat plantuml-server-url "/" plantuml-output-type "/~h" encoded-string)))
And this worked.
(well the server https
endpoint appears to be borked so I had to change server url to http, which is again quite terrible, but whatever)
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
FYI while server mode no longer works out of the box because of this issue, jar mode works.
@natrys method does work for me (thanks for sharing), but special/accented characters are not rendered correctly:
Does anyone know a workaround for that?
@jjnilton yeah I failed to account for multi byte code points. I am not really knowledgeable around these APIs in Emacs, but this might solve your issue:
(defun hex-encode (str)
(string-join (mapcar (lambda (c) (format "%02x" c)) (string-as-unibyte str))))
On a tangential note, I had discovered https://kroki.io/ who provide a unified API for quite a number of backends including plantuml. I have brushed up my old wrapper code that shows preview using it, in case it's useful to anyone: diagram-preview.
That solved it, thanks @natrys. Good to know about kroki.io, looks great, thanks for sharing your package.
Summary
Checklist for pull requests
develop
branch instead ofmaster