[texworks] Current status of Tw development

[Paul A Norman]

P.s. regarding printing pdf  from preview - I should add that from
using TeXworks as a typesetter, and the proofing point of view, it is
extremely important to at some point to actually print out (and
preview), not from the poppler library Tw uses, but from pdf viewers
that are going to render the typeset material as your users will
likely see it and print it. And I understand that many assume Acrobat
Reader is still way up there in the numbers.

There are things that the poppler previewer may never show or print
properly (presently many \pdfcomment type macros  for example)

Paul

On 18 November 2010 11:59, Paul A Norman <paul.a.norman at gmail.com> wrote:
> Hi,
>
> I would agree that some indication be given on the file menu to the
> user that printing from TeXworks is not yet (if ever) supported, and
> at that point what about a sub menu offering to open the ( already
> typeset document ) in whatever their default pdf viewer is on their
> system (possibly utilising and altering Jonathan Kew's script - 26th
> January 2010). TW.app.launchFile(TW.target.fileName); may need to
> change .ext if this is on the Editor's File menu as well.
>
>  [Are we calling Scirpts from C++ for ver 0.4 ?]
>
> Checking first that there is an already typeset document? And assuming
> that their default viewer can print. If there is no default, their
> system should prompt them to set one up, or associate the .pdf with
> something (that would be OS dependant).
>
> Menu something like?
>
> /File/
>  <other File menu items first >
>  /Print/
>   [sub menu]     /Printing Not Available/  [always greyed]
>                        /Open in default Pdf Viewer/ [normal colours -
> mouseover: for printing]
>                        /Experimental Printing/  [greyed - or normal colours
>                                                            for
> where/when it is already possible - OS detected]
>  <other File menu items ... >
>
> Make /Open in default Viewer/ and /Experimental Printing/ (above)
> available if document is typeset, otherwise greyed out.
>
> There is an advantage if some tricky features are not implemented all
> at once in all OS-es, for example if Linux gets it first or whatever.
>
> Here, as each Tw release advances, /Experimental Printing/ would be
> available to more OS-es. Benefit is that in effect it would be a
> staggered or progressive roll out, so if one OS gets it before the
> others this becomes a benefit from a development point of view, in
> that we are trouble shooting one thing at a time, rather than be
> deluged by all sorts of problems relating to specific OS-es and their
> sub-releases on a new or enhanced Tw feature..
>
> Final result being that all OS-es have it available --- if it is to be
> implemented at all.
>
> I could live with my default pdf viewer handling printing. Just
> include details in TeXworks manual as to how to set/change a default
> pdf viewer in each main OS.
>
> And perhaps get another possible Print sub menu item in - specifically
>
>      /Open in Acrobat Reader/ [mouseover: if available]
>
> Paul
>
> On 18 November 2010 08:30, Stefan Löffler <st.loeffler at gmail.com> wrote:
>> On 2010-11-17 18:41, Bruno Voisin wrote:
>>> Le 17 nov. 2010 à 17:48, Stefan Löffler a écrit :
>>>
>>>> I agree that printing would be nice to have. As would be, e.g.,
>>>> continues display in the previewer. Or preview abilities for dvi and ps.
>>>> Some people might request that as well (and probably rightly so).
>>>> However, none of that is currently available in a state to be put in a
>>>> stable release right now (IMHO, at least).
>>> That's perfectly fine by me. I'm sorry if you felt my messages as pressure towards adding printing in the upcoming release, that wasn't my purpose. Here I was just reacting to the presentation of TeXworks as just another PDF viewer, as opposed to an integrated TeX GUI. It's perfectly fine that it doesn't include printing yet, or continuous scrolling. Better omit something IMHO than offer it half-baked and inconsistent, it can be added later when it's ready for all platforms. That was the point of my original message: make sure the patch is omitted in official builds if it's not available for all platforms.
>>
>> No problem :). We're going in the same direction, anyway ;).
>>
>>>> Well, printing should work on Linux by use of the command line tool lpr.
>>>> This may be available on all typical installations, but I don't know for
>>>> sure. Besides, its quite old (there are other, more modern systems like
>>>> CUPS, but again you need to have it installed, you need a proper
>>>> interface, ...) and options (like which pages to print, ...) are device
>>>> specific. So it works, but hasn't been tested thoroughly. The same
>>>> system would be used on Mac, but if it's typically available there at
>>>> all I have no idea.
>>>> On Windows, the postscript code is sent to the printer directly if that
>>>> is supported.
>>> Mac OS X's printing architecture is built on top of CUPS, which has been purchased by Apple a few years back. The command line tool lp is included
>>>
>>> http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/lp.1.html
>>
>> Thanks, this at least is reassuring.
>>
>>> There are probably OS X frameworks integrating this with an interface, or maybe Qt does this, but on such areas I must confess my total ignorance.
>>
>> Well, there is a Qt interface. It can print vector data, provides a nice
>> printer settings dialog, etc. What it can't do is render pdf/postscript.
>> Poppler, on the other hand, can render pdf, but in the language binding
>> we use (poppler-qt4) it can't produce vector data :(. That's how the
>> image-printing function was implemented, BTW.
>>
>> Cheers,
>> Stefan
>>
>>
>