Presently reading the Opus 12 PDF Manual (that seems to be for version 12.8), and found a few things that might be typos and the like:
p105, The Use wildcards option lets you use standard pattern in this field [...]
-> The Wildcards option lets [...]
p105, The Use wildcards option lets you use standard pattern when defining the text [...]
-> The Wildcards option lets [...]
p105, The Enables partial matching option means that the string [...]
-> The Partial match option means that [...]
p105, Type: You can use this to search for files or folders of a certain type.
-> Filetype: You can use [...]
p105, For example, instead of specifying *.bmp for the Name matching field, you can select Bitmap Image from the drop-down to find bitmap files.
=> ! Example no longer works this way, sentence needs to be updated!
p112, One manual sort mode is active, [...]
-> Once manual sort mode [...]
Typo found in the Prefs:
Prefs -> Folders -> Folder Display -> Show cloud storage status icons in the Status columr
Typo: -> column
The Prefs typo is actually the control not being quite wide enough for some font/DPI combinations, with the n clipped and looking like an r. Still needs fixing, either way!
For our own notes, another I just noticed in the pattern matching syntax:
[af-j] matches either a, f, g, h or j -- (i is missing)
Good to know... will keep an eye out for any "typos".
Two more general things I noted about the PDF manual:
I use the PDF-XChange Viewer (free version) to read/highlight/add notes... and the page numbers the Opus pages show (at the bottom right of each page) do not match the page numbers used by the PDF Viewer... this makes pointing out typo locations slightly confusing... thus I quote sentences to allow for a quick text find (hopefully). Not sure this can be fixed... since the cover page, and the index pages do not start the numbering of the pages, it seems...
Pardon my nitpicking, I have been editing probably thousands of wiki pages, where I very much look out for layout consistency. Seems the Word to PDF export meddles with the vertical spacing in the output? E.g. on p119 (Viewer p125) the section title "Display" is the last line on that page... it would look nicer one page onward... there are quite a few such "strange" offsets in the layout. Again no idea if this can be fixed... In Open Office Writer I would probably try to add a Ctrl+Enter ("snaps" the section title to the top of the next page) to the source Word document... (just a thought).
And at 200% DPI there is even more space (I think it generally increases with DPI as there are more opportunities for tighter font kerning the higher the resolution goes):
With Opus 12.9.1 on Windows 10, DPI (if you mean the Windows desktop DPI, then at native 1080p 100% (i.e. no scaling)). I do not scale fonts or the aspects of tools.
Mystery solved, we fixed that internally a few days ago and I didn't notice the fix was already in my version.
All of the above manual typos and clipped control are now fixed.
RE the PDF comments in the 3rd reply:
Page numbering: I think this is just how things are, since PDF viewers (or maybe the PDF format itself, I'm not sure) tend to be too simple to match up to standard book page numbering, where the first page is not always "page 1".
e.g. The copyright notice and table of contents at the start of books is often not part of the main page numbering, and might use roman numerals instead, with the first page that the table of contents points to being page 1:
It's Not always the case, of course. I have two books on my desk and one is like that while the other has the first page of the ToC as page 1. But, even then, an even more common example: The cover of a book is usually "page 1" in a PDF viewer, but almost never "page 1" in the page numbering of a book. So PDF viewers displaying proper books are usually at least one page out, unless there's some way to offset their numbering and make the cover "page 0" or something. Maybe there is? It'd have to use negative numbers or roman numerals or something for books where page 1 starts after the ToC etc., which I've never seen so far (but I try to avoid PDF files, to be fair).
This only matters when viewing a PDF on a computer. PDF, with is narrow width, page breaks and margins wasting screen space, is an awful format for on-screen viewing and only good for printing, IMO. We have HTML Help (F1 in the program) and web (link at the top-right of this forum) versions of the manual for online viewing.
I'm not sure if we can force page breaks in the help file editor we use, which generates all formats of help file. It'd make sense if it moved headings to a new page if there was only room for the heading, when outputting to page/paper-based formats, but I don't know if it is sophisticated enough to be able to do that.
On PDF page numbering... as always in such instances it's all a whole lot more complicated than one might hope. Thus why it was an "issue" at all. Even though I really like PDF-XChange Viewer, it already had the issue that facing pages could not be offset by one page to actually be able to view a 2 page image on the same screen. I like reading PDF documents, mostly because I can add highlights and comments...
p119, [...] and to clear it click the xsymbol.
-> [...] the x symbol.
=> The space between the graphics "x" and the text "symbol" is missing.
p122, The Filename and Folders field both take a wildcard string [...]
-> The File names and Folder names fields both take [...]
p122, applies to files - otherwise, [...]
-> applies to files --- otherwise, [...]
=> Replace all minus " - " with " " em-dash " " in the manual, if not in a formula. In Word --- is used to enter an em-dash.
p122, In the screenshot above you can see that nothing has been defined for the Show Filter, but the Hide Filter is set to hide any files that end in .ini or .bak, any folder called .svn (no wildcards were used so the folder name must match exactly), [...]
=> The image does only shows the Hide Filter tab, the Show Filters tab is hidden. Image would require an update, or two images.
=> The examples mentioned ".ini or .bak, any folder called .svn" are not shown in the image, but would really be interesting to check up on.
p123, The Color field lets you assign [...]
-> The Fill color field lets you assign [...]
p123, • Toolbar: This lets you choose a toolbar or toolbar set that will be automatically displayed whenever this format is applied.
=> The "Toolbar:" line no longer seems to exist in Opus 12.9.1 dialogue window. Would also require an image update on this page.
That seems to be a bug in the PDF generation software, and I don't know if we can do much about it. It's correct in the F1 help and online versions of the manual, and the HTML behind it has a space after the img tag, which the PDF version seems to omit. It's very minor so we're going to leave it as-is.
The "Toolbar:" line no longer seems to exist in Opus 12.9.1
It is still there, but only when editing a saved folder format, not ad-hoc editing the current format in use by a folder tab.
I've clarified the docs on that point, as well as adding information about the two checkboxes which appear at the bottom of the same page when editing a saved format.
