[texworks] Call for Help: Testing for the upcoming release

[Philip Taylor]

Dear Stefan, copy list :

Stefan Löffler wrote:

> On 12.03.2016 04:55, Philip Taylor wrote:
>> 0) [new, NEW, IMPORTANT] The preview no longer remembers the page and
>> view visible across compilations; it now opens at logical page 1 after a
>> re-compilation whereas it used to re-open at the previously selected
>> page and view.  This is a major regression.
> 
> Indeed, this should not happen. I thought this was fixed. Anyway, I will
> investigate. I create an issue on GitHub for this
> (https://github.com/TeXworks/texworks/issues/718)
> Could you tell me how you compile your documents (is it a one-step
> process like running "pdflatex", a script that performs several actions,
> ...; could any part of that process potentially leave the pdf in a
> broken state (such that if it were reloaded at that time, the page and
> view would not exist - in which case Tw will default back to the
> beginning of the document).

It is a single-step process as far as the user is concerned, in that all
of my documents are processed with XeTeX as they commence with the
pragmat "% !TeX Program = XeTeX".  However, my understanding is that
internally XeTeX involves two distinct steps :  (1) the generation of an
.XDVI file, and (2) the conversion of that .XDVI file to PDF  using
XDVIPDFMX.  However, the behaviour using TeXworks 0.4.5 r. 1280 is as
wished, in that the PDF is re-opened after re-compilation at the
previously obtaining view, whilst with TeXworks 0.5 (travis-ci) [r.
b9e7fa5, 11/03/2016 23:09] the PDF re-opens at logical page 1 but with
the currently selected magnification rather than the default (e.g., if
the PDF was previously showing logical page 198 with two levels of zoom,
it re-opens at logical page 1 with two levels of zoom).

However, I now notice that this appears to happen (a) only in
single-page view and not in either of the "continuous" views, and (b) if
the preview visibly closes during compilation (i.e., not for very short
files where the preview is open at a very early page in the document).

>> 1) Two-page view allows only the option "two-page continuous" -- if one
>> has selected 2-page view with "Fit to page", then although spreads are
>> normally displayed as desired, taking a hyperlink from the T-o-C to an
>> arbitrary page results in the spread being displaced vertically upwards
>> on the screen, and a small part of the following spread being visible
>> below.
> 
> Please note that links in PDFs can specify a particular view to jump to
> (e.g., zoomed in on a particular part of a graphic or whatever). In many
> cases, they will actually specify the point where the real heading is
> (which could be in the middle of a page) and Tw will therefore jump to
> that location and will therefore scroll in such a way that the actual
> anchor point (headline) is in the top left corner (if possible), in
> compliance with the PDF standard.

OK, that could be what is happening.  But in single page "show all"
view, it does not; following the hyperlink causes the target page to be
displayed such that all the content is visible rather than with the
target location in the top-left corner of the screen.  I have just
re-tested using both the Table of Contents (where one could reasonably
expect the target to be a page rather than an element of a page) and the
Index (where the target could indeed be a page element rather than a
page per se) and the behaviour is identical :  the target page is
displayed displaced vertically upwards (IFF there is following material
that will allow the spread to scroll vertically) in two-page continuous
mode.  Also, testing using the Index entries for "Wood, Joy" (11) and
"Thomas, Liz" (11) causes the page to be displayed identically for both,
whereas in reality Joy Wood appears approximately 1/3 of a page higher
on page 11 than Liz Thomas, suggesting that it is not a place-specific
PDF target that is the cause.

>> Could "two-page view" be unbundled from "continuous" so that
>> taking a hyperlink to an arbitrary page will result in the target spread
>> still being correctly positioned on the screen (all visible, no other
>> spread visible) ?
> 
> In principle it could. However, that would require some more coding (to
> implement a new page layout mechanism) and bring with it new
> user-visible options (that need to be translated before the release). So
> I'm afraid this is not going to happen for this release but after.
> GitHub issue: https://github.com/TeXworks/texworks/issues/719.

Fully understood.

>> 2) With the advent of 2-page view, a new default magnification is needed
>> : "Fit to spread"
> 
> I agree  with the same time limitation as above.
> That said, I wonder how many people would actually use "Fit to spread"
> in the end... 

I would respectfully suggest "all those who select two-page view" !

> Maybe it would be more logical to have "Fit to Width" work
> as "Fit to spread" on two-page non-continuous mode. Then there would at
> least be the workaround "switch to two-page non-continuous" > "Fit to
> width" > "switch to two-page continuous".

More than happy with that suggestion :-)

>> 3) When opening a file from an existing TeXworks window, could TeXworks
>> open the new file with the same size and placement as the one from which
>> it has been opened. [...]

> This is a very interesting idea... I created an issue on GitHub
> (https://github.com/TeXworks/texworks/issues/717) to keep track of it.

Excellent, thank you.

>> 4) [new] "Actual size" (for my test case, at least : A6) does not
>> display at actual size on screen; there would seem to need to be
>> configuration parameter that one can vary in order to get "Actual size"
>> to be correct; [...]

> There is such a parameter :). It's under Edit > Preferences... > Preview
>> Screen resolution. Unfortunately, there is no easy-to-use calibration
> tool, yet, though, but you can use external tools (or a ruler and a
> calculator ;)) to determine the appropriate value.

No problem, I can hold the real A6 original against the screen !

>> 5) [new] "Shift-magnify" re-positions the displayed content that appears
>> to bear no relationship to the position of the cursor at the time that
>> "shift-magnify" was used; it would be more intuitive (and more useful)
>> if "shift-magnify" ensure that the previous cursor position remained
>> visible and (ideally) centered the newly zoomed page around the previous
>> cursor position.
> 
> Agreed - GitHub issue https://github.com/TeXworks/texworks/issues/721.

Thank you.

>> 6) [new] A test file yields (in the log) :
>>
>> Overfull \hbox (0.58942pt too wide) in paragraph at lines 20--20
>> []\bodyfont brian.smith0000 at btinternet.com[]  |
>>
>> With "Hide console window" set to either "Automatic" or "On success",
>> this error message disappears; could TeXworks detect the presence of
>> overfull box messages in the log and treat them as errors ?
> 
> Whether the console is closed depends solely on the exit status code of
> the process that is doing the typesetting. It has nothing to do with the
> actual log output (or what scripts etc. do with it). If TeX exits with
> status code 0, the typeset run is considered a success, otherwise it's a
> failure.

OK, then I will ask Akira-san to investigate the possibility of
returning non-zero when overful boxen are reported.

Thank you Stefan.
** Phil.