[texworks] Updated builds of TeXworks for OS X

Charlie Sharpsteen chuck at sharpsteen.net
Mon May 16 02:12:03 CEST 2011

On Sun, May 15, 2011 at 5:22 AM, Stefan Löffler <st.loeffler at gmail.com> wrote:
> On 2011-05-15 03:01, Charlie Sharpsteen wrote:
>> I just rolled up two new TeXworks binaries for Mac OS X:
>> The first binary is for OS X 10.6.x and is x86_64 only. The second
>> binary is for OS X 10.5.x -- 10.6.x and contains both ppc and i386
>> architectures.  I don't actually have a PPC-based machine to test on,
>> so if someone who does could try out the Leopard build and let me know
>> if it works that would be awesome!
> Wow, this is awesome, thanks! How did you manage universal builds (I'm
> asking primarily out of curiosity, as this has been a topic of some
> discussion in the past, and not being a Mac user myself I couldn't make
> heads or tails of (some of) the posts.

The easy part is that CMake takes care of creating universal builds of
TeXworks as you can define the variable CMAKE_OSX_ARCHITECTURES as a
semicolon-delimited list at configure-time. For example, to set up a
build that would produce a three-way universal binary:

    cmake .. -DCMAKE_OSX_ARCHITECTURES="ppc;i386;x86_64"

The hard part is ensuring that the TeXworks dependencies (Qt, Hunspell
and Poppler) are available as universal binaries for each architecture
you desire.  There are basically two ways to achieve this:

  1. The easy way: Configure the dependencies with CFLAGS set to
include multiple `-arch` flags. i.e: `CFLAGS="-arch ppc -arch i386
-arch x86_64"`. Also, if building a project that configures using GNU
autotools, pass `--disable-dependency-tracking` to `configure` so that
GCC isn't set up to compile with `-E`, `-S`, `-M`or `-save-temps`
flags which are incompatible with using multiple arch flags. You will
need to build using the GCC compilers provided by Apple in XCode as
GNU GCC does not understand how to handle multiple arch flags.

  2. The hard way (some configure scripts just can't be convinced to
set method 1 up right): Configure the dependency for one
architecture---then build and istall it to a temporary location.
Repeat for each architecture you need. Combine the resulting
single-architecture binaries into a universal binary using the `lipo`
tool. This is tedious and messy, but from what I understand this is
what Apple's GCC does "under the hood" when it gets passed multiple
arch flags.

Luckily, the TeXworks dependencies build into universal binaries just
fine using method #1. Qt has special configure flags that handle
universal binary creation. Thank yourselves for having such a short
dependency list as it makes this whole operation much easier.  I may
look into adding custom Homebrew formulae for `qt.rb` and
`hunspell.rb` alongside `poppler.rb` that take care of building
universal binaries.

>> Compared to the first build I did, there are three improvements:
>>   - The first build does not contain a proper Info.plist file which
>> means OS X will not recognize it as an editor for `.tex` files.
> Can you (or someone else) check if this also resolved the problem
> reported in comment #3 at
> http://code.google.com/p/texworks/issues/detail?id=494#c3, please (i.e.,
> the menu entry "About TeXworks..." in the Apple menu read only
> "About...")? I think it might, but it would be nice to have some
> confirmation.

It looks like creating a proper Info.plist solved the problem with
having "About" instead of "About TeXworks" in the Apple menu. Revision
818 seems to solve the problem with multiple "Settings and Resources"
entries. The "About TeXworks" entry is still disappearing if all
windows are closed.

>> Current issues with the builds:
>>   - If anyone is feeling artistic, it would be nice to come up with a
>> snazzy background image for the Drag N' Drop installer.
> I'm not feeling particularly artistic, but what kind of image are we
> talking about? Is there a webpage with some screenshots, maybe?

Wolfgang Schuster provided an excellent example of the desired effect.
It looks like we will need:

  1. A PNG file that contains the background image.

  2. A DS_Store file that tells OS X how to position the directory
contents and points to the PNG file as a background image.

If someone comes up with a nice background, I could probably create
the DS_Store file.

>>   - I noticed that the last official Mac build includes the following
>> Qt plugins:
>>     * accessible
>>     * codecs
>>     * graphicssystems
>>     * imageformats
>>     * script
>>     Currently, my builds don't contain any of these plugins and seem
>> to run fine (given extremely limited testing). Are any of these
>> plugins necessary?
> This may have been related to the Qt version, the flags used to build
> it, and/or deployment system used. From the looks of it, I would suggest
> the following methods of testing:
> 1) Do scripts (in particular QtScript scripts, e.g. the normal .js
> files) work? If so, the "script" plugin is probably included already.

QtScript scripts look like they are working.  If anyone notices that
they aren't, let me know!

> 2) Do you have an exhaustive list of codecs when you click on the second
> status bar widget from the right in the editor window? If so, "codecs"
> are probably taken care of.

I get a pretty long list, so this may "work on my machine" at least.
I do need to spend some time validating that the codecs can actually
be used.

> 2) Do pdfs with embedded .png or .jpg files display correctly?
> 3) Can you drag&drop image files (e.g., .png or .jpg) into the editor
> and they get converted to \includegraphics{...} commands automatically?
> If 2 and 3 work, then "imageformats" (and perhaps "graphicssystems") are
> taken care of.

All images seem to display correctly. Drag and drop of PNG files
works. However, JPEG drag and drop causes TeXworks to open the JPEG
file for editing instead of inserting \includgraphics{...}. So it
looks like I may need to add some of the graphics plugins.


> Stefan

More information about the texworks mailing list