<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Stefan Löffler wrote:<br>
<br>
</div>
<blockquote type="cite"
cite="mid:22a749db-75e4-a40f-db09-695d20f9afa2@gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">Hi Phil,<br>
<br>
thanks for testing and sharing your ideas!
<blockquote type="cite">[...]<br>
</blockquote>
That looks correct.<br>
</div>
<blockquote type="cite">[...]<br>
</blockquote>
Absolutely. Please note, though, that at this stage I will likely
not add any new features (especially none that come with changes
to the user interface, which will then need translations, etc.).<br>
<br>
<blockquote type="cite"
cite="mid:e9c610e1-af15-4d4c-c05e-72b7c8b82a48@Hellenic-Institute.Uk">
<ul>
<li>[Bug] Attempting to save a new file as "Bundler.cover"
with "Save file as" set to "All files (*)" results in the
file being saved as "Bundler.cover.tex"; there appears no
way to save it as "Bundler.cover" as desired. </li>
</ul>
</blockquote>
<br>
Interesting. This works for me as expected on Linux. I'll have to
look into it on Windows.<br>
</blockquote>
<br>
Thank you.<br>
<br>
<blockquote type="cite"
cite="mid:22a749db-75e4-a40f-db09-695d20f9afa2@gmail.com">
<blockquote type="cite"
cite="mid:e9c610e1-af15-4d4c-c05e-72b7c8b82a48@Hellenic-Institute.Uk">
<ul>
<li>[Requested features] Support for draggable rulers</li>
</ul>
</blockquote>
<br>
As a feature request, this is not likely to happen before this
release. That being said, what do you mean by "draggable"? (I
assume you mean rulers in the PDF preview?)<br>
</blockquote>
<br>
Draggable as in the Adobe CC suite — two rulers, one horizontal
(above the preview), one vertical (to the left of the preview, or
perhaps to the right for RTL UIs), from which one can drag guide
lines which then remain overlaying the preview to allow accurate
measurement, comparison, etc.<br>
<br>
<blockquote type="cite"
cite="mid:22a749db-75e4-a40f-db09-695d20f9afa2@gmail.com"> <br>
<blockquote type="cite"
cite="mid:e9c610e1-af15-4d4c-c05e-72b7c8b82a48@Hellenic-Institute.Uk">
<ul>
<li>Support for Ctrl +, Ctrl - & Ctrl 0 (zoom in, zoom
out, fit to screen). For that matter, Ctrl 1 (actual size)
would also be useful.</li>
</ul>
</blockquote>
<br>
I have all those (and more). Again, might be an OS thing (or
possibly a translation thing), but those functions are in the PDF
View menu and have the precise shortcuts you mention (except "fit
to screen", which probably translate to "fit to window", which for
me is Ctrl 3)<br>
</blockquote>
<br>
OK, I can now see that Ctrl-{1,2,3} & Ctrl-+/- do something; as
Ctrl-0 did not, I did not think to check the others ! But Ctrl-0
does nothing for me, and for me that is also perhaps the most
important. I instinctively hit Ctrl-0 to see a whole document,
since that shortcut is common to so many different programs.<br>
<br>
<blockquote type="cite"
cite="mid:22a749db-75e4-a40f-db09-695d20f9afa2@gmail.com"> <br>
<blockquote type="cite"
cite="mid:e9c610e1-af15-4d4c-c05e-72b7c8b82a48@Hellenic-Institute.Uk">
<ul>
<li> The ability to open multiple source files in separate
tabs of a single window</li>
</ul>
</blockquote>
<br>
This has been on my wishlist for a long time, but unfortunately
requires some more internal restructuring first (which is on the
way, not not yet completed).<br>
<br>
</blockquote>
Understood.<br>
<br>
<blockquote type="cite"
cite="mid:22a749db-75e4-a40f-db09-695d20f9afa2@gmail.com"> <br>
<blockquote type="cite"
cite="mid:e9c610e1-af15-4d4c-c05e-72b7c8b82a48@Hellenic-Institute.Uk">
<ul>
<li>Add an "Open-as" option, within which the encoding can be
specified.</li>
</ul>
</blockquote>
<br>
This could be nice. My preferred method would be to auto-detect
the encoding if possible, however.<br>
<br>
</blockquote>
If it auto-detects, then I think that if it detected anything other
than the default (UTF-8), it should alert the user to that effect.<br>
<br>
<blockquote type="cite"
cite="mid:22a749db-75e4-a40f-db09-695d20f9afa2@gmail.com"> Until
that's done, you can open the document, select the desired
encoding in the status bar and then hit "reload using selected
encoding". I know it's a bit cumbersome (especially if you need to
use it a lot), but it should work.<br>
BTW: There is also a "magic comment" to define the encoding [<a
class="moz-txt-link-freetext"
href="https://github.com/TeXworks/texworks/wiki/Magic-Comments"
moz-do-not-send="true">https://github.com/TeXworks/texworks/wiki/Magic-Comments</a>].<br>
</blockquote>
<br>
Yes, someone told me of that before. I have added it to those of my
legacy documents that I have been able to identify.<br>
<br>
<blockquote type="cite"
cite="mid:22a749db-75e4-a40f-db09-695d20f9afa2@gmail.com"> <br>
<blockquote type="cite"
cite="mid:e9c610e1-af15-4d4c-c05e-72b7c8b82a48@Hellenic-Institute.Uk">
<ul>
<li>Could TeXworks be enhanced to (a) recognise, and (b)
insert if absent, a BOM in UTF-8 files ?</li>
</ul>
</blockquote>
<br>
It should be recognized, and you can toggle the insertion from the
status bar (clicking on the encoding should open a menu which has
an entry "write utf-8 byte order mark").<br>
<br>
<blockquote type="cite"
cite="mid:e9c610e1-af15-4d4c-c05e-72b7c8b82a48@Hellenic-Institute.Uk">
<ul>
<li>Would it be possible to augment TeXworks such that, no
matter in which window Ctrl-F/R is typed, it is interpreted
in the context of the source window rather than the preview
window ? As this would be a change to current behaviour, it
would have to be specified by a user preference or similar.
And for the rare occasion where one <i>does </i>want to
search (but not replace !) in the preview window, perhaps
this functionality could be exposed by Ctrl+Shft+F or
similar.</li>
</ul>
</blockquote>
<br>
Hm, interesting idea, but I'd have to think about it.<br>
</blockquote>
<br>
Thank you.<br>
<br>
<blockquote type="cite"
cite="mid:22a749db-75e4-a40f-db09-695d20f9afa2@gmail.com"> <br>
<blockquote type="cite"
cite="mid:e9c610e1-af15-4d4c-c05e-72b7c8b82a48@Hellenic-Institute.Uk">
<ul>
<li>And/or — amend TeXworks to <i>not</i> steal focus from
the text-mode window when the PDF is displayed. A frequent
usage scenario is that one is performing a series of
search-and-replace experiments in the text-mode window while
observing the effect in the PDF window, and with the current
behaviour the next search is invariably a "Search PDF"
rather than a "Search text" as desired.</li>
</ul>
</blockquote>
<br>
You can (sort of) do that already. In the preferences under
Typesetting, select your tool, click "Edit..." and untick "View
PDF after running". The first time you tex a new document, you'd
have to open it manually (e.g. via "Window > Go to preview".
Any other time you open the tex, the pdf should still be opened
automatically, and TeXworks would not "steal" your focus.<br>
</blockquote>
<br>
Interesting, I will try that (and report back). Thank you, Stefan !<br>
<br>
But two other things while I think of them —<br>
<ol>
<li>The previewer does not seem to know which source documented
generated the preview. Let there be three files, 1.tex, 1.tmp
(a text file) & 1.pdf. Let 1.pdf be the result of compiling
1.tex. Then all the while that 1.tex and 1.pdf remain open,
hitting "Compile" in the preview window will cause 1.tex to be
compiled. But if one closes 1.tex, leaving 1.tmp & 1.pdf
open (1.tmp in the source pane, of course, being a text file),
then hitting "Compile" in the preview window causes the system
to attempt to compile 1.tmp<br>
<br>
</li>
<li>File/open in the preview window does not pre-select ".pdf" as
the extension as I would expect it to, leaving it at the default
of ".tex".</li>
</ol>
<p>** Phil.<br>
</p>
</body>
</html>