dump compile settings wish

I’d like to see a means of dumping compile settings to a file.

A search just now of Windows / Tech Support resulted in 633 hits for ‘compile’ among 43 pages. I’m guessing but I think Compile is your biggest issue. Yet there’s no way for us to tell you precisely what we’re doing.

An extra button somewhere on the Compile dialog could cause all the current settings plus internal stuff you’d like to see to be written to a file which we could then send in via email or copy/paste into the forum.

An addition to this is another control, a checkbox perhaps, that when checked would cause all user text to be replaced with something descriptive, for example, “scene <$n>”, thus you get to see the compile output, more or less, and we get to not send you copyrighted material. And the problem gets solved.

You should be able to export your Compile settings already. I’m away from my Windows machine right now, but it will either be a “Save…” button in Compile or under “Manage Compile Format Presets…” at the bottom of the “Format As” menu.

One of the Windows team should put me straight, though. :slight_smile: (Certainly on the Mac version you export Compile settings by going to “Manage Compile Format Presets…”)

All the best,
Keith

You’ve missed the point.

On Windows, the way to create the compile settings file is to go to File > Compile and click the blue arrow icon to the right of the “Format As” pop-up, then choose “Save…” from the bottom left and give your compile settings a name. You can then send that .ini file to support. As far as I can read your original request, that’s what you’re looking for.

There’s no checkbox to just replace all your text with other filler, but that would be a bit extreme. I understand the desire not to share your actual writing, but generally speaking, if we actually needed to see a sample of what your compiled output looked like, replacing it all with “scene <$n>” wouldn’t end up being helpful–that much is going to be fairly clear from your settings. Usually what’s more helpful is a screenshot of the binder, since the structure of that affects your compile, and if you’re not comfortable with the titles there being seen, Paint will let you block or blur them; you could even just crop most of the text from the image, since what we’d really care about there is seeing the icons (which will indicate the file types) and the level structure.

That said, there are plans down the road for an option in compile to replace text when creating the compiled document, so that would allow a fairly straightforward way to set up something that would obfuscate the text–replace a bunch of letters with “e” or what have you–so you could compile your text and have a safe sample to send.

:open_mouth:

I think what the OP is asking for is a text file with the current compile settings so the user knows what settings they are using. I think there is confusion for some users about all the options that are available.

You accidentally deleted the bit after “You’ve missed the point” where you politely explain what the point actually is.

Well, looks like some simplification of my simple post is in order.
Maybe some visual aids:

Scenario: Someone has a problem compiling and they send tech support a note that says “I did everything right but the compile output is crap. What’s wrong?” and tech support says back “Do it again just the same but this time click this other button and send me the file at blah/blah.” and the user does that and tech support immediately identifies the problem and the user is embarrassed and happy.

To make that happen (see first red text) a file gets generated with all of Scrivener’s compile settings and (see second red text) other stuff necessary for compile like what the Binder/Manuscript looks like and all those Compile As-Is Meta-Data checkboxes that may or may not be used in a compile.

Now I did not create this scheme, an application collecting information for use by tech support, but I have worked one place that used it. I’ve also worked as lead developer on a large GUI-client/server/driver app with RAID controllers behind it where I got to triage all the bugs. Everything was blamed on the GUI, meaning me, even when the real problem was obviously, to me, deep inside a RAID controller. So I know that users will tell you they did something when they didn’t and tell you they didn’t do something when they did. And they won’t know they’re doing it. In addition to obvious differences between users and tech support like continents and languages there’s a difference in terminology. Users have their terminology, tech support has theirs, development probably has another and, from reading the manual, there are several more in the documentation. A way around all this is for tech support to learn directly what the Scrivener app knows. The file envisioned here will provide that. It might also be useful for areas other than compiling. I prefer to use human readable files for this sort of thing. Note that the CompileSettings ini files are not.

The magenta text above refers to, as Jennifer H. pointed out, obfuscating the user’s text so it can be legally viewed by tech support to help solve problems. This is something that would need to turned on and off only by the user. Here’s an idea on how to obfuscate, one’s a video and one’s a document: video pdf