You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 28, 2021. It is now read-only.
Currently, markdown documents including pictures are saved to/retrieved from the storage as a bundled .zmd (for zipped markdown) file. However this solution has a number of issues:
The system renames the file from .md to .zmd (and viceversa) depending on the presence (or absence) of embedded pictures, but this happens "on the back of the user", so it may look counter-intuitive.
If the file was shared when .md, the share link gets broken.
Text content is zipped and not indexable by OSs when the file is synchronized.
We should look into alternatives to preserve the filename. For instance:
Always save a .md and put the pictures alongside in the same folder, similar to browsers saving a complete HTML page (though they'd use a folder, which we cannot). Issues:
We'd need to keep the pictures on the CodiMD server as well, because when pushing the file from the EFSS to CodiMD the wopibridge cannot access other files in the folder.
To keep the content in sync, the pictures would need to be deleted and recreated at each save+close operation.
Risk of polluting the target folder with many pictures.
Always save a .md, pictures are only kept on the server and never synchronized.
Users never have their embedded pictures offline.
We could define a special "tag", e.g. [](embed-pictures) which is not rendered: if found at the top of the document, the file is saved as .zmd and the user gets the whole content.
Out of the above, my preference is to implement 2 as that would fix the current issues and keep the solution simpler to the user, though the [](embed-pictures) tag would need to be documented and is kind of an advanced feature.
To be noted that in all cases it is not expected that users modify the file outside of the app, therefore in particular the first issue in 2. may not be such a big deal.
The text was updated successfully, but these errors were encountered:
There's some consensus to ditch this .zmd file type, as preserving shared links and versions/revisions is important.
Another option is to exploit the soon-to-come "file picker" interface in ownCloud, and make sure files embedded in CodiMD are actually already present in the cloud storage. In that case, we just keep the .md file and that's all.
This last option requires quite some developments:
On ownCloud/CERNBox, a file picker UI with the ability to create a public link on the fly, such that the result returned to CodiMD is a link of the form https://cernbox.cern.ch/index.php/s/<hash>/download.
On CodiMD, replacing the "upload file" dialog with the file picker when in appliance mode. The /uploads folder in CodiMD would be entirely "disabled".
Currently, markdown documents including pictures are saved to/retrieved from the storage as a bundled
.zmd
(for zipped markdown) file. However this solution has a number of issues:.md
to.zmd
(and viceversa) depending on the presence (or absence) of embedded pictures, but this happens "on the back of the user", so it may look counter-intuitive..md
, the share link gets broken.We should look into alternatives to preserve the filename. For instance:
.md
and put the pictures alongside in the same folder, similar to browsers saving a complete HTML page (though they'd use a folder, which we cannot). Issues:.md
, pictures are only kept on the server and never synchronized.[](embed-pictures)
which is not rendered: if found at the top of the document, the file is saved as.zmd
and the user gets the whole content.Out of the above, my preference is to implement 2 as that would fix the current issues and keep the solution simpler to the user, though the
[](embed-pictures)
tag would need to be documented and is kind of an advanced feature.To be noted that in all cases it is not expected that users modify the file outside of the app, therefore in particular the first issue in 2. may not be such a big deal.
The text was updated successfully, but these errors were encountered: