A macro to embed docx files into your Tiddlers

[talha131]

talha131_macro_docx.json (1.2 KB)

This tiddler adds a macro docx that lets you embed DOCX files into your tiddlers.

You can either pass the direct URL of the docx file.

<<docx "https://example-url.com/file.docx">>

Or you can add a tiddler and set its _canonical_uri field to the URL of the docx file, in which case you will use the macro like this

<<docx "example tiddler">>

In this case, the macro will read _canonical_uri from your “example tiddler.”

Here is a screenshot to demo this feature

[Springer]

Awesome!

Is there any reason we can’t just use the _canonical_uri field in the same single tiddler as the one that displays the docx? (I tried, and played around a bit with settling tiddler type field to application/docx and such, no luck with getting display to work.)

Alternately, could the macro accept a field-name instead of a directly-typed url string, so that the power of fields can be harnessed in managing docx files?

Even in this more limited form, I’m very happy to be able to access a docx without needing to convert it to pdf. Kudos!

-Springer

[talha131]

@Springer

Is there any reason we can’t just use the _canonical_uri field in the same single tiddler as the one that displays the docx? (I tried, and played around a bit with settling tiddler type field to application/docx and such, no luck with getting display to work.)

That’s a good point. I didn’t think about it. I will add it.

If I understand you correctly, you mean, if the src is empty, like

<<docx>>

Then the macro should read _canonical_uri of the <currenttiddler>.

@Springer

could the macro accept a field-name instead of a directly-typed url string, so that the power of fields can be harnessed in managing docx files?

Another interesting idea. So what will be the syntax?

<<docx "example tiddler" "docx-url-field">>

Which would mean, read docx-url-field of example tiddler.

[Springer]

I imagine that ideally, it would default to looking at _canonical_uri field for the current tiddler, then if anything else is specified, it would be another fieldname of the current tiddler, and only last (if there are two strings) would one optionally invoke another tiddler. I’m not sure what kind of syntax would be best, though, as I’m not familiar with best practices there…

On defaulting to the current tiddler’s field: I would hardly ever want to be pointing to another tiddler’s field for this kind of solution. Unlike an image, which might play an inline role in many tiddlers, a docx is “heavy” content.

Could a docx viewer behave more like pdf viewing in tiddlywiki? (For a pdf, you can put the url in _canonical_uri, and then specify tiddler type to application/pdf, and viola — that tiddler simply becomes a vehicle for displaying the pdf, no further macro needed.)

-Springer

[talha131]

Thanks for getting back to me

@Springer

I imagine that ideally, it would default to looking at _canonical_uri field for the current tiddler, then if anything else is specified, it would be another fieldname of the current tiddler, and only last (if there are two strings) would one optionally invoke another tiddler. I’m not sure what kind of syntax would be best, though, as I’m not familiar with best practices there…

On defaulting to the current tiddler’s field: I would hardly ever want to be pointing to another tiddler’s field for this kind of solution. Unlike an image, which might play an inline role in many tiddlers, a docx is “heavy” content.

All great points. I will make the necessary changes as soon as my time frees up a bit. I plan to publish it as a plugin.

@Springer

Could a docx viewer behave more like pdf viewing in tiddlywiki? (For a pdf, you can put the url in _canonical_uri, and then specify tiddler type to application/pdf, and viola — that tiddler simply becomes a vehicle for displaying the pdf, no further macro needed.)

Woah! Just this morning, I was thinking about this feature.

I think we can pull it off this way.

1. If the mime type of a tiddler is set to application/msword
2. And if the _canonical_uri field is set
3. Add <<docx>> macro to the body tiddler

It will require some changes in the ViewTemplate.

Great idea.

Note:

More Docx mime types

[Springer]

@talha131

I think we can pull it off this way.

1. If the mime type of a tiddler is set to application/msword
2. And if the _canonical_uri field is set
3. Add <<docx>> macro to the body tiddler

It will require some changes in the ViewTemplate.

Somehow with pdf, you don’t have to do anything at all in the text field (“body” of tiddler); tiddlywiki swaps in the viewtemplate needed for pdf as soon as _canonical_uri is set. But I don’t have the tech skills (or time at the moment) to look into how that’s done.

[TW_Tones]

I think if you import or drop files on a wiki there is use of the deserializer and the type / mime/type is set. TiddlyWiki has a list of deserializers.

@Springer

you don’t have to do anything at all in the text field

• @Springer is correct ask if you want more help

[talha131]

I realized that this filter can be simplified to the following

<$set name="url" filter="[<__src__>is[tiddler]get[_canonical_uri]else<__src__>addprefix[https://view.officeapps.live.com/op/embed.aspx?src=]]">

I am waiting for some free time to publish it as a proper plugin in a plugin library so that updates like these become easier.

[talha131]

@TW_Tones

I think if you import or drop files on a wiki there is use of the deserializer and the type / mime/type is set. TiddlyWiki has a list of deserializers.

Thank you @TW_Tones. Your hint led me to the parsers in the TiddlyWiki source code.

In view of @Springer suggestion, I am trying to add a parser in the source code that would show the docx files in an iframe. In this regard, I have a confusion that I have posted here

How to use BinaryParser for my custom Parser if a condition is false

What’s the end goal? I am trying to add a parser module for docx files. If I fix the problem then I will open a PR in the official repository. What have I done so far? (function () { /*jslint node: true, browser: true */ /*global $tw: false */ "use strict"; const BinaryParser = require("./binaryparser"); var DocxParser = function (type, text, options) { var element_uri = { type: "element", tag: "iframe", attributes: { src: { type: …

[TW_Tones]

@talha131 best of luck with this work, unfortunately I don’t know much more on the deserializers, however I want to point out that it is possible to export HTML and open it in Word, and save word files in a format that the html can be imported to TiddlyWiki. This is an alternative to direct docx support and arguably needs no new deserialiser.

I can’t find the discussion that referred to this but it should be documented online.

[TW_Tones]

FYI: I see a deserialiser as appropriate here Is there a mime type or deserialiser for JavaScript function like in bookmarklets and posted to the developer category.

[mwiktowy]

@talha131 Thank you for working on this. I’ve been looking for something to display remote Word files inline like you can with PDFs.

If this could be made into something that handles things transparently once you set the mimetype, that would be perfect.

/Mike

[talha131]

@mwiktowy

If this could be made into something that handles things transparently once you set the mimetype, that would be perfect.

Well I have opened up a pull request on Github. You can share your feedback or opinion there too.

There are two issues that create hurdles in “handling things transparently”.

1. Unlike PDF Viewer, this feature depends on an external service, Microsoft’s live.com. PDF viewer is natively supported in all modern browsers. MS Office docs aren’t.

2. It cannot work without _canonical_uri. There is no straightforward way to display MS Office docs from binary data.

[Mohammad]

@talha131

this feature depends on an external service, Microsoft’s live.com.

I assume this also needs to have an account on live.com am I right?

I get this error when I try your example in the first post

[talha131]

@Mohammad

I assume this also needs to have an account on live.com am I right?

No. You don’t need an account at all.

Your _canonical_uri is incorrect, perhaps.

talha131_macro_docx.json (2.7 KB)

Please try the attached json. I have added some valid examples to it.

[Mohammad]

Thank you! It works now!

[talha131]

talha131_macro_docx.json (2.7 KB)

Updated version with a bug fix