Keep imported word file as .doc or .docx

[dropshot]

I'd like to request an option to import Word files into the reference area and keep them in their native format. IIRC, this was something you could do in early versions.

I ask because I use Scrivener for planning academic courses and often have to import syllabi and other word doc files with complex formatting and pagination that gets disrupted by the import routine. My workaround is to do two imports, one of the file directly and a second of the file that's been converted to pdf.

[shorn]

I agree. I tried to do this using "File:Import:Research Files as Aliases..." but it would not let me choose a Word file at all.

[JoRo]

Why not just use project bookmarks?

Slàinte mhòr.

[perezbalen]

I agree. Just let us choose to import docx, whithout touching them. Like they are psd files or pdfs,

You don''t have to preview it even, if that's too much of a hassle.

I just want to have some docx files on my binder, so I can use Scriveners organization scheme. As it's now, I have all my research files on scrivener, except the docx, which need to be on a separate folder, somewhere else on my computer.

[lunk]

Why not simply save the docx file as a pdf and then drag the pdf to the binder? Why do you need the original Word file in the binder, inside Scrivener?

[gr]

A)

Someone said it used to be a thing in Scriv 2, which makes me wonder if this behavior might be tued to whether on has the "accept all file type" preference enabled. Not near my computer, so can't check at this time.

B)

A simple use case for having this feature is one where the final output format is docx (and maybe that gets touched up in the final round in Word. It is all very well to produce a pdf version, but ine is still ging to keep the Word file, right? It is at that point a master file. It does seem like it would be useful if there was scope for keeping this in the Research folder in Scriv -- keeping it together with everything elses associated with that project.

gr

P.S. Might throw some folks though, and special steps would then be required to import word docs in the transformational way into the Res folder then.

[KB]

The trouble with this is that if you imported a .docx file like that, you wouldn't be able to edit it, and you'd only be able to view it using whatever Quick Look preview is available on the machine (probably decent if you have Word installed, pretty poor if not). You'd also be limited to the Quick Look preview in how you could look at it - no way of zooming, saving the position of the page you were looking at etc, since Quick Look previews don't do any of that. It would be a pretty frustrating way of referring to the file, all in all.

Also, to keep things simple, all texts imported into Scrivener are converted to editable text.

Thus there are no plans to add anything like this, I'm afraid.

All the best,
Keith

[gr]

Yeah, I imagine it might be a source of confusion for users if Scriv was presenting any of the doc content to users.*

-gr

* Of course, if such docs were treated like (some) other alien files that must be opened in an external editor and just showed a filetype document icon in the editor pane this would remove the psychological suggestion that there was directly editable text there. Just saying.

[perezbalen]

I'm sure there are a lot of features in scrivener that a lot of users don't use. But that doesn't mean they should be removed. If I write alone, I have no use for collaborative features. But if I don't?

Clearly there are cases where writers need to jump through hoops to get their Word files in their Scrivener ecosystem. And the user should not be wasting time doing that.

I get that ideally, all text files should be editable. But pdf are not, and that's not a problem.

I get that you don't want to confuse the user with text files you can't edit on the editor. Maybe don't enable the feature by default. Maybe ad a big neon sing that says "Not editable".

But a user knowledgeable enough to use bookmarks, or extra folders, or one that converts all his docx to pdf, probably wont be confused when presented with an option to treat a docx file as one that could only be opened or previewed with an external editor (probably, that's what they want).

[AmberV]

There already is an “advanced” opt-in way of doing this: create an alias to the .docx file using whatever tool you prefer (Finder for example) and then drop the alias into the binder. There you go.

As noted we don’t make that easy because it would be confusing.

[nontroppo]

I use aliases for most tasks and they are really great (I love how quicklook gets you great views of the content, especially Excel spreadsheets). But, because I try to use Scrivener projects as one-ring-to-bind-them "repositories", that I can move about without worrying about aliases, there are cases where I want to Cold Archive a DOCX I have received that is relevant to the project (in collaborative academia we get lots of these), and then I end up making projects within folders and move folders, which then just increases the cognitive friction of remembering either project as projects and project in folders and remembering which is which. It isn't a major thing and KB has been clear so I'm not advocating for change, but just wanted to give my usecase parameters.

AmberV, perhaps it would be possible to manually "hack" the project bundle to add a storage subfolder and alias from within the project bundle and add them to the binder, do you think that could that work? It gets me a viewable (not editable) document accessible from the binder in a project which is fully portable... I can't remember off the top of my head how flexible aliases (as oppose to soft links) are when moved around.

[gr]

AmberV, perhaps it would be possible to manually "hack" the project bundle to add a storage subfolder and alias from within the project bundle and add them to the binder, do you think that could that work? It gets me a viewable (not editable) document accessible from the binder in a project which is fully portable... I can't remember off the top of my head how flexible aliases (as oppose to soft links) are when moved around.

Total speculation: Moving the resulting project around on that machine seems like it ought to keep those aliases targeted, but I assume those inward aliases would break if you moved the project between machines (or shared them with another machine via dropbox). Am betting zipping a project and unzipping it in a diff location on the same machine would also break inward aliases.

[kewms]

I'm not sure what functionality a non-editable DOCX file brings that a PDF file wouldn't...

Katherine

[AmberV]

I’m not sure what functionality a non-editable DOCX file brings that a PDF file wouldn’t…

There aren’t many good reasons for doing so:

• The contents will not be added to the search index (PDFs will).
• Sure, you can hit ⌃⌘O to open it in LibreOffice or whatever, but that’s also pretty much the primary function of a Bookmark.
• And Bookmarks can be viewed in the main editors, so even that isn’t an exclusive capability.

The only real advantage I can think of is if you need both of these conditions:

1. The original document (maybe it has complicated layout, pending track changes, whatever Scrivener doesn’t support).
2. And you want metadata, notes, an index card and the other benefits that come along with being a binder item.

Even the latter is of slim benefit since a proxy index card created specifically to hold a bookmark to a .docx file is only two actions less convenient to open (⌃⌥O versus ⌃⌥⌘N + Return), and potentially the same level of convenience for mouse users. I use the “library card” method for all kinds of stuff, myself. And if you’re used to using Bookmarks to jump around in your project, the shortcut sequence to use them may well be more engrained into muscle memory than Open in External Editor.

Given how marginal the advantages are, and how confusing it would be to have text files you can’t edit in the binder, actually adding this as a capability really makes no sense. I think the undocumented method I described above is sufficient for those that are really set on the idea despite the alternatives.

Aliases

Aliases are kind of halfway in between symbolic and hard links. They link to the inode rather than the path structure (for non-geeks, it’s a bit like the full zip code instead of the friendlier street address, but more precise), and thus are resilient to the path changing for both the alias and the target—but they are weaker where it comes to source locations that come and go (external drives for example), and particularly in scenarios where the alias is going to be transmitted using non-Mac interfaces. In my experience they can survive movement across volumes with the following conditions:

• If moved together with the target using Mac native methods (including Apple’s provided cp and mv commands), the alias will update to point to the target’s new location.
• If you move or copy the alias by itself to a different volume, then it will remain pointing at the original resource on the other volume.
• If you move the target by itself to a different volume (Command-drag by the way) then the alias on the original volume will break. However, if you later move the item back into its original location, the alias will heal! This is where they do have some similarities to symbolic links.

So give the above, aliases should work even in cases where the project is removed from a context where its aliased research material exists. I.e. if you copy your project to another machine (even from a .zip file) and work on it, your links will be broken for the duration of the session. But when you zip the project up and return to the original machine, plug the external drive back in, et cetera, the aliases will start working again—all thanks to its somewhat hybrid nature. (And that hybrid nature should protect it from non-Mac native archival tools as well.)

Scrivener’s treatment of aliases is a little more robust than one just sitting in the Finder. If the alias was created in a more recent build, then Scrivener would have also stored the original path used to create it, and if the alias itself breaks it will use that path to attempt relocating it, so long as the relative structure around the target is the same. This can help them survive being translocated across machines using cloud technology, where user folder names may differ, and the source material is translocated as well.

So in theory it could mean such an inward facing alias would heal itself in cases where the project ends up being loaded in a different account with a similar folder hierarchy around the target (in this case the project itself). Certainly something to test a few conditions with before committing to though! It does at least qualify under the “move both alias + target together” rule of thumb, and given that the relative structure within the project folder should not be changing, the auto-heal behaviour of Scrivener should also in theory repair them each time you switch machines. (And incidentally, we do something very similar for linked editor images now, too.)

As for safe storage areas within the project (that is, areas that won’t be automatically reclaimed by the orphaned file recovery feature), I would try the root level within the project—where “Snapshots”, “Quick Look” and other folders are. That exemption exists specifically because, with a project’s open nature off of Macs, Windows users tend to use that top level for exactly that kind of convenience—project backups protect these loose files, and they travel around with the project, but aren’t technically a part of it (of course it does kind of negate the idea of keeping backup times down, and most people doing that would probably prefer to know about the alias / shortcut method of outsourcing storage).

Welp, that’s probably way more about aliases than anyone wanted to know.

[nontroppo]

The original document (maybe it has complicated layout, pending track changes, whatever Scrivener doesn’t support).

This is my major reason at least (I get many DOCXs with the most baroque table layouts imaginable, commented and tracked, they totally break when converted and cannot be used as intended when ossified into a PDF, I regularly need to be able to send them back out functional when necessary...). Thanks all, and especially AmberV for the detailed reminder about aliases