The hardware and bandwidth for this mirror is donated by METANET, the Webhosting and Full Service-Cloud Provider.
If you wish to report a bug, or if you are interested in having us mirror your free-software or open-source project, please feel free to contact us at mirror[@]metanet.ch.
TeXShop was only possible because Apple provided developers with pre-built objects for crucial tasks: NSTextView for an editor, and PdfKit for a preview window. When the project started, I anxiously looked through the Pdf API's to see if Apple provided a routine to replace the old pdf file being displayed by a new version of the file; they did.
Apple cannot anticipate or fully support all possible uses of their objects. When a new pdf is displayed in a window, it is always opened at the top of the file. If the view should be scrolled to a new position, I have to do that myself. But the API's assume that scroll bars are mostly manipulated by users, and provide only a vague "scroll region to visible" command for programmers to scroll the preview window. Moreover, if the programmer tries to scroll the pdf when it is opened, that scroll produces an annoying flash. I wrote Apple complaining about the flash, and they told me that there is nothing they can do to fix it. So I have to fix it at my end.
When a LaTeX source file is opened, TeXShop reads the file and displays the text in a source window. Then it checks to see if a related pdf file is available. If so, TeXShop opens the pdf in a preview window using a routine I wrote named "showWithPath". Later when the user typesets, TeXShop switches from the original pdf to the new pdf using a routine I wrote named "reShowWithPath".
The "showWithPath" code is straightforward and I have no problems revising it. But "reShowWithPath" is an entirely different matter and I dread having to even look at it. This is the piece of code that determines the scroll location of the old pdf, loads the new pdf, and then scrolls the new pdf to that same location. It also contains code which hides the screen for a fraction of a second so nobody sees the flash and then uncovers the screen before the user notices a pause and complains. All that scrolling is far from trivial because Apple doesn't provide code to do it automatically. If the user has eliminated part of the text before typesetting, the old scroll location may no longer occur and the code has to gracefully adjust. Just writing about "reShowWithPath" gives me the shivers, and having to modify it leads to nightmares. I hope I never have to touch it again.
The bugs fixed in version 5.33 are related to these routines. If you receive the source code of a document from a friend and open it in TeXShop, there is no pdf file to display and so "showWithPath" is never called. When you typeset, TeXShop calls "reShowWithPath", but there is no previous version and thus no previous scroll position. In this special situation, the revised "reShowWithPath" just initializes the pdf and displays it without scrolling. That same situation occurs when you begin writing a new document in TeXShop and haven't yet typeset it.
Each source document in TeXShop corresponds to an NSDocument object in computer memory. This object contains the source text and all the windows which might be needed to process it: source window, log window, console window, preview window, etc. If you close the source window, then all of this data is removed from computer memory. But if you close one of the auxiliary windows, like the preview window, it is removed from the screen, but all the data in NSDocument still exists in memory. If you typeset again, the preview window will reappear in its old position. This is not what users expect, since they believe that closing the window made it go away entirely. The final bug fix maintains that illusion by opening the window at its beginning, as though it were being opened for the first time.
These binaries (installable software) and packages are in development.
They may not be fully stable and should be used with caution. We make no claims about them.