Difference between revisions of "MacOSX version of Scribus"

From Scribus Wiki
Jump to: navigation, search
m
m (Stable: Added link to full installation instructions.)
 
(26 intermediate revisions by 11 users not shown)
Line 1: Line 1:
{{Discussion Index}}
+
[[Category:MacOS]]
 +
=Native version of Scribus for Mac OSX=
 +
==Stable==
 +
* You can grab the latest stable version of Scribus from [[Download|here]] or you can get full installation instructions (including installation of GhostScript) [[OS X - Installing Scribus on your Mac the easy way|here]].
  
On the Scribus mailing list, Andreas Vox has started an interesting discussion on bringing Scribus natively to Mac OSX. It turns out that Martin Costabel has also been working on this with his fink packages for Qt/Mac Scribus. Craig Ringer is also working on porting, and pushing changes into 1.3cvs as they're made suitable for inclusion.
+
==Development==
 +
* Add Macports link
 +
* Add Fink link
 +
* [[Scribus and Homebrew]] (compile through package manager)
  
== Status ==
+
= Obsolete =
 +
* Native Aqua version
 +
** [[http://docs.scribus.net/index.php?lang=en&page=install5 Official Docs How to building the native Aqua version of Scribus 1.3.5 from SVN using MacPorts and Qt4 ]] - Instruction on building the native Aqua version of Scribus from SVN
 +
* X11 version
 +
** [[Installing Scribus on Mac with MacPorts]] - How to install and run Scribus 1.3.3.9 ''(27/05/2007)''
 +
** [[Installing Scribus from CVS sources on Mac OS X]] - Howto on installing Scribus from CVS sources through Fink
 +
** [[Installing Scribus on Mac OS X]] - Howto on installing the stable version of Scribus through Fink
 +
** [[Installing Scribus on Mac Intel]] - from the Scribus Archives
  
=== Status of Scribus 1.3cvs vanilla CVS (unpatched): ===
+
==Obsolete PPC OSX==
 
+
* <del>Scribus 1.3.x on MacOSX is still work in progress, but there are very usable, frequently updated binary test builds. Details are here http://www.scribus.net/?q=macosx</del>
* Working
+
* <del>Builds of the '''native Aqua version''' are now available from [http://sourceforge.net/project/showfiles.php?group_id=125235&package_id=201484 sourceforge] (choose the 1.3.5svn version)</del>
** Building against Qt/Mac
+
* <del>[http://aqua.scribus.net aqua.scribus.net] is the place go for the '''native Aqua version''', when you want to know more details and download the latest packages (but this link now seems to redirect to a general page)</del>
*** You may need to edit <code>libqt-mt.la</code> and remove the <code>-framework blah</code> entries if libtool chokes with a weird error while linking the final Scribus executable.
+
* <del>[http://bugs.scribus.net/view.php?id=2015 List of all known issues] &mdash; check this list before reporting new errors
** Plugins
 
*** Script plugin still untested though
 
** fontconfig ('''required''' for useful operation on MacOS/X)
 
*** May require <code>export LDFLAGS=" -lfreetype -lexpat "</code> and/or <code>--with-extra-includes</code> to work.
 
** finding the bundle path and resources dynamically at runtime if built with <code>--enable-bundle</code>
 
** static path build works fine too
 
** CUPS (with fink <code>cups-devel</code> package or add-in CUPS headers; Apple doesn't ship the headers in 10.3)?
 
** Operation from a .app bundle . The bundle must be hand constructed, and library paths on the executable need manual fixing, so it's only halfway there. Still, it works.
 
* Not working
 
** Usable performance. App pauses for annoying periods when drawing some dialogs (eg prefs) and when performing some tasks on the canvas. Appears related to menus display / re-creation.
 
** Loading of Mac fonts
 
*** We need a way to ask the system what kind of font we're dealing with - TTF, OTF, or Type 1. Freetype should load them OK and fontconfig can find them but we need to know exactly what kind the font is and neither Freetype nor fontconfig appear able to tell us that.
 
** Automatic assembly of a working .app bundle
 
* To investigate
 
** Printing
 
** Python
 
 
 
Issues solved by patches or tweaks not yet integrated:
 
* ?
 
 
 
== Join in with your opinion! ==
 
 
 
 
 
http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009442.html
 
 
 
I noticed that you still require X11 for the MacOSX version of Scribus.
 
 
 
I managed to compile Scribus 1.2.1 with Qt/Mac native and I wondered
 
if you'd like to get some hints how it is done. In fact it was quite
 
easy
 
once I solved my libtool problems (screenshot attached :-) )
 
 
 
So this is what I did:
 
 
 
0. Started with the Scribus 1.2.1 sources
 
 
 
1. configured Scribus to use Qt/Mac inbstead of the fink Qt version
 
 
 
2. replaced all gdk-* sourcefiles with empty files
 
 
 
3. commented out all #include <X11.h> etc.
 
 
 
4. Removed GC from scpainter
 
 
 
5. Rewrote scpainter::end():
 
 
 
void ScPainter::end()
 
{
 
        QImage qimg(m_width, m_height, 32, QImage::BigEndian);
 
        QRgb * bits = (QRgb *) qimg.bits();
 
        int words = qimg.numBytes() / 4;
 
        art_u8 * p = m_buffer;;
 
        for (int i=0; i < words; ++i) {
 
                art_u8 r = *p++;
 
                art_u8 g = *p++;
 
                art_u8 b = *p++;
 
                art_u8 a = *p++;
 
                *bits++ = qRgba(r,g,b,a);
 
        }
 
        bitBlt(m_target, 0, 0, &qimg);
 
}
 
 
 
 
 
6. libtool nuisances:
 
 
 
6a)  Apply fink patch to use correct -bundle for libtool
 
 
 
6b)  Remove -s option (stripping is no good idea if you want to link
 
plugins)
 
 
 
7. Make Scribus ignore any "-psn_*" commandline options passed by Qt
 
 
 
8. Adjust a few #includes to MacOSX
 
 
 
9. Created a rudimentary Scribus.app/ bundle (thanks to Ronald Florence
 
who did the same for LyX so I just had to replace a few strings)
 
 
 
The application still uses the files (plugins etc.) which Scribus
 
installs to /usr/local.
 
The following libraries get linked:
 
 
 
/Applications/local/Scribus.app/Contents/MacOS/scribus:
 
/sw/lib/libjpeg.62.dylib (compatibility version 63.0.0, current version 63.0.0)
 
/sw/lib/libart_lgpl_2.2.dylib (compatibility version 6.0.0, current version 6.16.0)
 
/usr/local/lib/libfreetype6.dylib (compatibility version 6.2.0, current version 6.3.4)
 
/usr/lib/libcups.2.dylib (compatibility version 2.0.0, current version 2.5.0)
 
/usr/lib/libssl.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7)
 
/usr/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7)
 
/sw/lib/liblcms.1.dylib (compatibility version 2.0.0, current version 2.12.0)
 
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.1.1)
 
/sw/lib/libtiff.3.dylib (compatibility version 3.6.0, current version 3.6.1)
 
libqt-mt.3.dylib (compatibility version 3.3.0, current version 3.3.3)
 
/sw/lib/libpng.3.dylib (compatibility version 3.0.0, current version 3.0.0)
 
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.0.0)
 
 
 
I still have problems with some plugins and some icons don't show, but  
 
otherwise it's usable.
 
Anyone who want's to test and help finishing it to a proper MacOSX
 
application?
 
 
 
Regards
 
Andreas
 
 
 
Ah, yes, the screenshot:
 
 
 
http://nashi.altmuehlnet.de/pipermail/scribus/attachments/20050305/a9711066/scribus-screen-shot-small-0001.jpg
 
 
 
 
 
http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009443.html
 
 
 
http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009444.html
 
 
 
 
 
Looks great.. erm.. what replaces the gdk sources then?
 
 
 
and what replaces the X call(s) in scfonts.cpp ? Does this mean you always
 
have to add in the font paths via the additional font paths setup?
 
 
 
Craig
 
 
 
 
 
http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009447.html
 
 
 
This does seem extremely interesting. I've been meaning to try an Aqua-
 
native port of 1.3cvs for a while, but I just don't have the mac
 
development experience, and there was the gdk-pixbuf issue to consider.
 
 
 
Like Craig Bradney, I'd be very interested in knowing how you handled
 
fonts and how you worked around the gdk dependencies.
 
 
 
From what I see in your library list below, I see that you still link to
 
quite a few fink-supplied libraries. I imagine we'd have to ship
 
prebuilt copies of those, or statically link them, with any
 
"installable" Aqua Scribus build. Sound about right?
 
 
 
 
 
'' 9. Created a rudimentary Scribus.app/ bundle (thanks to Ronald Florence
 
who did the same for LyX so I just had to replace a few strings)''
 
 
 
 
 
That's very, very useful to know.
 
 
 
Did you end up using Xcode for all this, or just tweaked the existing
 
build to use Qt/Aqua?
 
 
 
 
 
''/sw/lib/libjpeg.62.dylib (compatibility version 63.0.0, current  version 63.0.0)''
 
 
 
 
 
Does MacOS X not provide libjpeg? That's from fink by the looks...
 
 
 
 
 
''/sw/lib/libart_lgpl_2.2.dylib (compatibility version 6.0.0, current version 6.16.0)''
 
 
 
 
 
I imagine we'd have to bundle or statically link libart.
 
 
 
 
 
''/usr/local/lib/libfreetype6.dylib (compatibility version 6.2.0, current version 6.3.4)''
 
 
 
''/usr/local/lib . Interesting. Did you compile a Mac-native version of freetype yourself, or use an installer package or something?''
 
 
 
''/usr/lib/libcups.2.dylib (compatibility version 2.0.0, current version 2.5.0)''
 
 
 
 
 
Glad to see we can rely on MacOS/X for CUPS libraries.
 
 
 
 
 
''/usr/lib/libssl.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7)''
 
 
 
''/usr/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7)''
 
 
 
''/sw/lib/liblcms.1.dylib (compatibility version 2.0.0, current version 2.12.0)''
 
 
 
 
 
Fink again. I guess that'd be another static linking candidate.
 
 
 
 
 
''/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.1.1)''
 
 
 
 
 
Is this MacOS/X's libc equivalent? Or does it provide the core Aqua
 
routines etc?
 
 
 
 
 
''/sw/lib/libtiff.3.dylib (compatibility version 3.6.0, current version 3.6.1)''
 
 
 
 
 
Hmm, you got libtiff from fink too. Again, I'm rather surprised OS/X
 
doesn't include that.
 
 
 
 
 
''libqt-mt.3.dylib (compatibility version 3.3.0, current version 3.3.3)''
 
 
 
''/sw/lib/libpng.3.dylib (compatibility version 3.0.0, current  version 3.0.0)''
 
 
 
 
 
libpng from fink too :-(
 
 
 
 
 
''Anyone who want's to test and help finishing it to a proper MacOSX application?''
 
 
 
 
 
Me!
 
 
 
Especially if you can give some more detailed info, especially about how
 
you did the build and where the various libraries are from.
 
 
 
One thing I'm curious about... I know MacOS/X has five different major
 
APIs:
 
 
 
        Carbon        (Cleaned up OS/9)
 
        Classic        (Virtual OS/9 for unchanged apps)
 
        Cocoa          (Native MacOS/X Objective C/Aqua)
 
        Java          (duh!)
 
        POSIX/BSD/X11  (unix-style apps, usually console or X11 based)
 
 
 
but I was always under the impression they were rather separate, and one
 
couldn't for example write a POSIX/BSD app that used Cocoa (Aqua)
 
graphics. I also thought Cocoa apps had to link to 'Libraries' and
 
'Frameworks' that were different from the POSIX/BSD style shared
 
libraries.
 
 
 
Do you know if this distinction is less strict than I thought, and one
 
can mix and match to an extent? Or is Qt doing some magic to protect us
 
from these issues? Can we do things like use the MacOS/X font APIs? Have
 
you built Scribus as a Cocoa application, a POSIX/BSD app, or some
 
hybrid of the two?
 
 
 
If you know where I can go to find out more about MacOS/X development
 
and porting from UNIX, that'd be really handy too...
 
 
 
(It's funny - I don't actually like macs. But I still want to help port
 
Scribus across.)
 
 
 
--
 
Craig Ringer
 
 
 
 
 
http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009448.html
 
 
 
On Sat, 2005-03-05 at 09:41 +0100, Craig Bradney wrote:
 
 
 
''and what replaces the X call(s) in scfonts.cpp ? Does this mean you always have to add in the font paths via the additional font paths setup?''
 
 
 
I expect fontconfig, as used in 1.3, should work fine for this job. It
 
probably won't permit the use of MacOS9 style resource-fork-based fonts
 
(PostScript / Type 1 and TrueType) or OS/X native style .dfont fonts,
 
though.
 
 
 
I'm rather more curious about what replaced gdk-* and the more general
 
issues with how it all works, though.
 
 
 
--
 
Craig Ringer
 
 
 
 
 
http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009452.html
 
 
 
Please sign me up for the porting/testing effort for the native Aqua
 
Scribus. I spent months last year trying to get it to build. Alas, I
 
don't know C++ at all, and always had to stop when I ran into the
 
screenpaint/X11 calls: just didn't know how to work around them.
 
 
 
I've gotten pretty knowledgable about building and deploying app bundles
 
from Qt, however: I'm comfortable with Qt/Mac from a build standpoint,
 
so I think I can help there.
 
 
 
It may not be possible to have the ideal binary distribution, which is a
 
~ standalone, drag-and-drop app bundle. One can do that if you compile Qt
 
to be statically linked, rather than dynamically linked. However, I know
 
Scribus has other external dependencies as well. Still, if Scribus can
 
be built against a static Qt, then it should be simple to isolate the
 
other external dependencies (libtif? etc.) into a Mac pkg installer. A
 
standard Mac user in Scribus' target market (publishing, graphics) isn't
 
going to want to install all of Qt just to run Scribus, even if you
 
provide a binary installer (I maintain PyQt for the Mac with a binary
 
installer, so I have some insight here).
 
 
 
The example of Gimp.app (a Mac app bundle of Gimp 2.2.x) is instructive
 
here: it's become wildly popular in terms of downloads because it wraps
 
all the Gimp binaries and GTK libraries into a single app bundle. Its
 
only external dependency is Apple's X11 environment.
 
 
 
One area where we'd have to tread carefully is if the Scribus build
 
links to Fink libraries. That complicates matters, for several reasons.
 
One, the goal should be to make Scribus as standalone/isolated as
 
possible; I don't think that requiring a separate installation of Fink
 
should be part of this. Also, the Fink leaders are serious about
 
enforcing GPL on their packages: I was warned last year when I asked
 
about making an X11 app bundle of Scribus that I'd have to carefully
 
document all my steps, make all my source code available, etc. I decided
 
all that was too complex for me to undertake by myself. If Fink winds up
 
being part of this equation, then I just want to highlight the due
 
diligence that would need to be taken.  Perhaps Martin can provide
 
advice on this front.
 
 
 
Another question: where should this project be hosted? My little
 
AquaScribus app launcher is available from the Scribus site, as well as
 
from my own server, but it's a very small download. Depending on the
 
libraries, a Mac pkg installer of Scribus could be 20-50 megabytes to
 
download. Can the Scribus servers in the UK handle this, or should a
 
Sourceforge project be set up for the back end?
 
 
 
I'm incredibly excited about this: I've been wanting to ditch my
 
Microsoft/Adobe toolchain in my publishing business (I publish about 50
 
poetry books per year via POD) for some time, but Scribus hasn't been
 
quite mature enough for my needs. (I have used it successfully with
 
cover design only, so I know that Scribus can handle commercial work,
 
but those covers were more work than a comparable version in InDesign
 
would be.) With 1.2.1 supporting styled text import, it looks like
 
Scribus may have crossed that threshold. And with NeoOffice J running
 
natively on the Mac, that and Scribus.app would allow me to ditch X11
 
for everything except Gimp.
 
 
 
So, just let me know what I need to do! I can't wait!
 
 
 
- --
 
Cheers,
 
 
 
Kevin Walzer, PhD
 
 
 
 
 
http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009460.html
 
 
 
Kevin Walzer wrote:
 
 
 
<i>
 
The example of Gimp.app (a Mac app bundle of Gimp 2.2.x) is instructive here: it's become wildly popular in terms of downloads because it wraps all the Gimp binaries and GTK libraries into a single app bundle. Its only external dependency is Apple's X11 environment.
 
</i>
 
 
 
Gimp.app uses a whole bunch of dynamic libraries from Fink. It just puts
 
them into the bundle and ships them with the app. Scribus.app could do
 
the same, at least for the smaller libs. I agree that libqt is perhaps
 
better linked statically if possible.
 
 
 
<i>
 
One area where we'd have to tread carefully is if the Scribus build links to Fink libraries.
 
That complicates matters, for several reasons.
 
One, the goal should be to make Scribus as standalone/isolated as possible;
 
I don't think that requiring a separate installation of Fink should be part of this.
 
Also, the Fink leaders are serious about enforcing GPL on their packages:
 
I was warned last year when I asked about making an X11 app bundle of Scribus that I'd have to carefully document all my steps,
 
make all my source code available, etc. I decided all that was too complex for me to undertake by myself.
 
If Fink winds up being part of this equation, then I just want to highlight the due diligence that would need to be taken. 
 
Perhaps Martin can provide advice on this front.
 
</i>
 
 
 
Actually I even annoyed the guy who distributes Gimp.app until he
 
provided a detailed account of his build procedure. He has such a text
 
now on his web site at
 
http://gimp-app.sourceforge.net/gimp.app.howto.txt, and I think this is
 
a good thing. It can be useful for example for a project like
 
Scribus.app. That's is the idea of this part of the GPL, namely to allow
 
others to learn from your work.
 
 
 
I don't see any conflict between Fink and a possible standalone
 
Scribus.app. I could even imagine a Fink package that produces this
 
standalone Scribus.app which could then be distributed from the scribus  
 
servers. Just because such a thing has not yet been done, doesn't mean
 
it is impossible.
 
 
 
There is another example of a Mac app bundle made with the help of Fink:
 
Nicotine.app http://nicotine-app.sourceforge.net/cgi-bin/wiki.pl. The
 
maintainer of this project (vasi) is also one of the main Fink
 
developers. On that page there are even two more app bundles made in the  
 
same way. All these app bundles are running with X11, though.
 
 
 
 
 
''So, just let me know what I need to do! I can't wait!''
 
 
 
 
 
The first and foremost point is to get this thing working.
 
 
 
All other questions about packaging etc are secondary. You remember that
 
Ben Reed had a scribus version using Qt/Mac already some 2 years ago,
 
but it never worked correctly. Maybe both Qt/Mac and scribus are now in
 
a shape that makes this possible, but this has to be seen.
 
 
 
--
 
Martin
 
 
 
 
 
http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009478.html
 
 
 
Craig Ringer wrote:
 
 
 
<i>
 
This does seem extremely interesting. I've been meaning to try an Aqua-
 
native port of 1.3cvs for a while, but I just don't have the mac
 
development experience, and there was the gdk-pixbuf issue to consider.
 
</i>
 
 
 
 
 
Since this post appears to contain more questions than others I'll
 
respond to this :-)
 
 
 
<i>
 
Like Craig Bradney, I'd be very interested in knowing how you handled fonts and how you worked around the gdk dependencies.
 
</i>
 
 
 
Ok, short one first: Fonts. I just commented out the body of
 
addXFontpath.
 
Currently I only have Courier/Luxi/Utopia etc from /usr/X11R6/bin.
 
Some work needs to be done here.
 
 
 
About the gdk-pixmap business: my first step was to delete/comment out
 
anything
 
which uses X11. I have a native LyX version based on Qt/Mac, so I know
 
this is
 
possible. Unfortunately when I started Scribus the main drawing area
 
was black.
 
 
 
Then I looked at the code and saw that in ScPainter::end() the libart
 
buffer is just
 
copied to an X pixmap. I then tried QImage for this:
 
   
 
   
 
    QImage qimg(m_buffer, m_width, m_height, 0, 0);
 
    bitBlt(target, 0, 0, &qimg);
 
 
 
 
 
That worked but after a while I noticed the colors where wrong. Some
 
testing and
 
thinking revealed that libart uses RGBA, while Qt uses ARGB. That's how
 
I arrived
 
at the current code: just copy  the libart buffer into a QImage
 
manually.
 
 
 
The gdk-sources are not needed at all, QImage/bitBlt do all the work.
 
This should also
 
work for other platforms btw.
 
I'm not sure if scrolling is as fast as in X11, but it feels ok.
 
Sometimes  I see artefacts
 
of half-drawn screens while scrolling, but once I stop everything looks
 
ok.
 
 
 
 
 
<i>
 
From what I see in your library list below, I see that you still link
 
to quite a few fink-supplied libraries. I imagine we'd have to ship
 
prebuilt copies of those, or statically link them, with any "installable" Aqua Scribus build. Sound about right?
 
</i>
 
 
 
 
 
That was my quick&dirty approach again. It was easier for me to use
 
fink.
 
 
 
 
 
<i>
 
Did you end up using Xcode for all this, or just tweaked the existing build to use Qt/Aqua?
 
</i>
 
 
 
 
 
No XCode, not even Eclipse. Just Developertools gcc 3.3.3, Terminal.app
 
and vi  :-)
 
The app-bundle is just a bunch of files where you have to copy your
 
executable to the right position and provide some information in an XML-
 
based Info.plist file.
 
I haven't produced icons yet, I will use the XCode tool for that.
 
 
 
 
 
 
 
<i>Does MacOS X not provide libjpeg? That's from fink by the looks...</i>
 
 
 
 
 
Yes. Couldn't find one in OSX.
 
 
 
 
 
<i>I imagine we'd have to bundle or statically link libart.</i>
 
 
 
Yes, unless you replace it by Cairo before ;-)
 
 
 
 
 
<i>Did you compile a Mac-native version of freetype yourself, or use an installer package or something?</i>
 
 
 
 
 
I installed the fink one but obviously configure found the one from X11.
 
 
 
 
 
<i>
 
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.1.1)
 
 
 
Is this MacOS/X's libc equivalent? Or does it provide the core Aquaroutines etc?
 
</i>
 
 
 
 
 
Yes, libc, libm and others.
 
 
 
<i>
 
> /sw/lib/libtiff.3.dylib (compatibility version 3.6.0, current version 3.6.1)
 
 
 
 
 
Hmm, you got libtiff from fink too. Again, I'm rather surprised OS/X doesn't include that.
 
</i>
 
 
 
 
 
I guess Apple needs Objective C routines for image handling most of the
 
time, so they have equivalents in their Cocoa framework.
 
 
 
 
 
<i>Especially if you can give some more detailed info, especially about how you did the build and where the various libraries are from.</i>
 
 
 
 
 
Maybe we can stick to the fink ones for the time beeing and get the
 
other
 
stuff right, first?
 
 
 
>One thing I'm curious about... I know MacOS/X has five different major APIs:
 
 
 
>        Carbon        (Cleaned up OS/9)
 
 
 
>        Classic        (Virtual OS/9 for unchanged apps) Emulator.
 
 
 
>        Cocoa          (Native MacOS/X Objective C/Aqua)
 
 
 
Objective C framework from Nextstep
 
 
 
>        Java          (duh!)
 
 
 
Has Cocoa bindings.
 
 
 
>        POSIX/BSD/X11  (unix-style apps, usually console or X11 based)
 
 
 
Can be mixed with Carbon. I think X11 and Qt/Mac are also based on Carbon.
 
 
 
It's all layered. I guess all graphics eventually end up in the Quartz
 
library.
 
For a single application it is very advisable to stick to one
 
framework, though.
 
 
 
 
 
> but I was always under the impression they were rather separate, and
 
> one
 
> couldn't for example write a POSIX/BSD app that used Cocoa (Aqua)
 
> graphics. I also thought Cocoa apps had to link to 'Libraries' and
 
> 'Frameworks' that were different from the POSIX/BSD style shared
 
> libraries.
 
>
 
> Do you know if this distinction is less strict than I thought, and one
 
> can mix and match to an extent? Or is Qt doing some magic to protect us
 
> from these issues? Can we do things like use the MacOS/X font APIs?
 
> Have
 
> you built Scribus as a Cocoa application, a POSIX/BSD app, or some
 
> hybrid of the two?
 
 
 
Qt/Mac app :-)
 
You can link to any framework you want, so now Scribus links to  
 
Posix/BSD
 
for non-graphics stuff and Qt/Mac and libart for graphics.
 
Cocoa is more difficult because that's Objective C.
 
 
 
Scribus already almost exclusively uses Qt for graphics. The
 
buffer-copy in
 
scpainter and the fontpaths are the only X11 dependencies as far as I
 
know.
 
 
 
 
 
> If you know where I can go to find out more about MacOS/X development
 
> and porting from UNIX, that'd be really handy too...
 
 
 
There are developer docs but mainly you can just use gcc/gdb/make etc.
 
You just have to read the Apple specific manpages for these tools, eg.
 
the special linking options of gcc for Darwin, -framework instead of -I,
 
or the fact that you can call gdb on a Mac.app application directly.
 
 
 
OK, the next steps would be:
 
 
 
* decide if we want to work with 1.2.1 or 1.3cvs
 
* fix the makefile for MacOSX (include the fink changes)
 
* the fontpath issue
 
* use dynamic paths to access Scribus.app/Contents/Resources instead of /usr/local/lib/scribus (We can build on some LyX work for  that)
 
* Provide a howto to compile Scribus for MacOS native (req. libraries, configure options, installation, ...)
 
* Test Scribus/Mac for regression wrt. Scribus/X11
 
* When this works try to get a self contained binary with bundled/static libs.
 
 
 
Ciao
 
 
 
/Andreas
 
 
 
 
 
http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009466.html
 
 
 
On Sat, 2005-03-05 at 20:49 +0100, Craig Bradney wrote:
 
 
 
> Sure its possible. In the worst case we can just supply all the libraries
 
> ourselves. Not very disk space friendly but once the X dependency is really
 
> gone it might not be that much really.
 
 
 
I think it'd be best to bundle or statically link all libs not included
 
in MacOS/X as shipped, if at all possible. Mac users seem happy to
 
accept somewhat bloated apps in exchange for standalone installs, and
 
this is probably something that should be taken into account.
 
 
 
It's probably not a big deal whether they're bundled as separate libs or
 
statically linked thanks to the Mac `.app' dir setup that lets you
 
collect up all files for an app into an "object" that behaves to the
 
user as it if was a single program binary.
 
 
 
--
 
Craig Ringer
 
 
 
 
 
http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009480.html
 
 
 
 
 
> OK, the next steps would be:
 
>
 
> * decide if we want to work with 1.2.1 or 1.3cvs
 
 
 
I'd suggest 1.3 as we arent adding any new features to 1.2.1. 1.2.x works
 
already on Mac. Ok its not so simple or pretty
 
 
 
> * fix the makefile for MacOSX (include the fink changes)
 
> * the fontpath issue
 
 
 
1.3 supports fontconfig.. I'm assuming fontconfig is ok via Fink. We will
 
strip the X dependency from 1.3 and rely on fontconfig soon enough.
 
 
 
We have a cairo build now, have had for ages, but its not fast enough to
 
switch yet. Your QImage idea might work on X11 just as quickly as libart
 
though..
 
 
 
Craig
 
 
 
 
 
http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009482.html
 
 
 
 
 
Two small remarks:
 
 
 
Andreas Vox wrote:
 
[]
 
>> >          /usr/local/lib/libfreetype6.dylib (compatibility version
 
>> 6.2.0,
 
>> > current version 6.3.4)
 
>>
 
>> /usr/local/lib . Interesting. Did you compile a Mac-native version of
 
>> freetype yourself, or use an installer package or something?
 
>
 
>
 
> I installed the fink one but obviously configure found the one from X11.
 
 
 
Actually, it found yet another one. The freetype from current Apple X11
 
is version 2.1.0 which is too old to work for scribus. Fink has versions
 
2.1.4 and 2.1.9, but they show other compatibility versions than what
 
you are showing.
 
 
 
>> >          /usr/lib/libcups.2.dylib (compatibility version 2.0.0, current
 
>> > version 2.5.0)
 
>>
 
>> Glad to see we can rely on MacOS/X for CUPS libraries.
 
 
 
But headers like <cups/cups.h> are not supplied by Apple. You need a
 
small package cups-dev from Fink (or wait 4 months for MacOSX 10.4).
 
[]
 
> * decide if we want to work with 1.2.1 or 1.3cvs
 
 
 
It is probably natural for scribus developers to eye 1.3x here, and I
 
would agree if this means that 1.3x will be cleaned up for the Mac.
 
Right now, I haven't yet got it working correctly.
 
 
 
- There is a bug in the prefs plugin that prevents the preferences
 
dialog from coming up, but it is not the same bug as the one in 1.2.1,
 
and I haven't yet identified it. There is another bug in the svgex
 
plugin, but this is less important than the preferences.
 
 
 
-  The colors are all wrong, again. I don't know which version of David
 
Purton's patch went into the cvs sources, but the result looks like with
 
the first version of his patch which was not correct for bigendian machines.
 
 
 
--
 
Martin
 
 
 
 
 
http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009483.html
 
 
 
 
 
Martin wrote:
 
 
 
 
 
> Two small remarks:
 
>
 
> Andreas Vox wrote:
 
> []
 
> >> >          /usr/local/lib/libfreetype6.dylib (compatibility version
 
> >> 6.2.0,
 
> >> > current version 6.3.4)
 
> >>
 
> >> /usr/local/lib . Interesting. Did you compile a Mac-native version
 
> of
 
> >> freetype yourself, or use an installer package or something?
 
> >
 
> >
 
> > I installed the fink one but obviously configure found the one from
 
> X11.
 
>
 
> Actually, it found yet another one.
 
 
 
 
 
You are right. Courtesy of word2x / libwmf.
 
 
 
...
 
> It is probably natural for scribus developers to eye 1.3x here,
 
 
 
 
 
Fine. I'll start with patching now :-)
 
 
 
 
 
> and I
 
> would agree if this means that 1.3x will be cleaned up for the Mac.
 
> Right now, I haven't yet got it working correctly.
 
>
 
> - There is a bug in the prefs plugin that prevents the preferences
 
> dialog from coming up, but it is not the same bug as the one in 1.2.1,
 
> and I haven't yet identified it. There is another bug in the svgex
 
> plugin, but this is less important than the preferences.
 
>
 
> -  The colors are all wrong, again. I don't know which version of David
 
> Purton's patch went into the cvs sources, but the result looks like
 
> with
 
> the first version of his patch which was not correct for bigendian
 
> machines.
 
 
 
 
 
This is Scribus/X11, yes? Is David Purton's patch changing the
 
gdk-sources
 
or libart or something else?
 
 
 
 
 
Ciao
 
/Andreas
 
 
 
 
 
 
 
http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009484.html
 
 
 
 
 
On Sat, 2005-03-05 at 19:18 +0100, Andreas Vox wrote:
 
 
 
> Ok, short one first: Fonts. I just commented out the body of
 
> addXFontpath. Currently I only have Courier/Luxi/Utopia etc
 
> from /usr/X11R6/bin. Some work needs to be done here.
 
 
 
Fontconfig should take care of that for now. In the medium term I'd like
 
to look at trying to access fonts via the MacOS/X font apis ... but that
 
might require things like a carbonized version of freetype that knows
 
about resource forks.
 
 
 
> No XCode, not even Eclipse. Just Developertools gcc 3.3.3,
 
> Terminal.app and vi  :-) The app-bundle is just a bunch of files where
 
> you have to copy your executable to the right position and provide
 
> some information in an XML-based Info.plist file. I haven't produced
 
> icons yet, I will use the XCode tool for that.
 
 
 
That's very useful to know.
 
 
 
> > Especially if you can give some more detailed info, especially about
 
> > how
 
> > you did the build and where the various libraries are from.
 
>
 
> Maybe we can stick to the fink ones for the time beeing and get the
 
> other stuff right, first?
 
 
 
That sounds sensible.
 
 
 
> >        POSIX/BSD/X11  (unix-style apps, usually console or X11 based)
 
> Can be mixed with Carbon. I think X11 and Qt/Mac are also based on
 
> Carbon.
 
 
 
Thankyou. I wasn't aware POSIX/BSD apps could use Carbon ... that's
 
extremely handy to know. It also eliminates one of my biggest concerns
 
with a Mac native port - the ability to use Mac-native APIs for font
 
access, accessing color profiles, etc without having to do some sort of
 
Objective-C wrapper layer.
 
 
 
> > If you know where I can go to find out more about MacOS/X development
 
> > and porting from UNIX, that'd be really handy too...
 
>
 
> There are developer docs but mainly you can just use gcc/gdb/make etc.
 
> You just have to read the Apple specific manpages for these tools, eg.
 
> the special linking options of gcc for Darwin, -framework instead of -I,
 
> or the fact that you can call gdb on a Mac.app application directly.
 
 
 
Good to know. I was more hoping for a "survial guide for UNIX
 
developers" though, ie what's different, how to handle issues like
 
resource forks, .app bundles, the number of different APIs, etc. I'll
 
have to check out the main dev docs - I had a quick look before but
 
didn't spot any sort of summary for folks coming from a *nix background.
 
 
 
> You should know that MacOSX is the most popular Unix on earth :-)
 
 
 
I just wish they'd integrate X11 more, so it wasn't the most popular
 
UNIX-like OS on earth and the only workstation one that encourages users
 
to avoid X11 ;-)
 
 
 
I like my network transparency.
 
 
 
> * decide if we want to work with 1.2.1 or 1.3cvs
 
 
 
I tend to agree with MrB re using 1.3cvs. While it'd mean a longer lead
 
time to get a stable, usable build, and more changes happening along the
 
way, it should mean less duplicated work and merging.
 
 
 
I guess I'll have to finish getting XCode and the dev tools set up on
 
the eMac at work.
 
 
 
--
 
Craig Ringer
 
 
 
 
 
http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009485.html
 
 
 
 
Craig Ringer wrote:
 
>  In the medium term I'd like
 
> to look at trying to access fonts via the MacOS/X font apis ... but
 
> that
 
> might require things like a carbonized version of freetype that knows
 
> about resource forks.
 
 
 
 
 
AFAIK resource forks are deprecated in MacOSX.
 
 
 
 
 
> Thankyou. I wasn't aware POSIX/BSD apps could use Carbon ... that's
 
> extremely handy to know. It also eliminates one of my biggest concerns
 
> with a Mac native port - the ability to use Mac-native APIs for font
 
> access, accessing color profiles, etc without having to do some sort of
 
> Objective-C wrapper layer.
 
 
 
 
 
That's why they created Carbon in the first place :-) -- noone wanted
 
to switch
 
to Objective C.
 
 
 
 
 
> > > If you know where I can go to find out more about MacOS/X
 
> development
 
> > > and porting from UNIX, that'd be really handy too...
 
> >
 
> > There are developer docs but mainly you can just use gcc/gdb/make
 
> etc.
 
> > You just have to read the Apple specific manpages for these tools,
 
> eg.
 
> > the special linking options of gcc for Darwin, -framework instead of
 
> -I,
 
> > or the fact that you can call gdb on a Mac.app application directly.
 
>
 
> Good to know. I was more hoping for a "survial guide for UNIX
 
> developers" though, ie what's different, how to handle issues like
 
> resource forks, .app bundles, the number of different APIs, etc. I'll
 
> have to check out the main dev docs - I had a quick look before but
 
> didn't spot any sort of summary for folks coming from a *nix
 
> background.
 
 
 
Look for Unix porting guide. Manpages for gcc, glibtool, otool, etc.
 
 
 
I also found
 
 
 
        http://sveinbjorn.vefsyn.is/writings
 
and
 
 
 
        http://kernelthread.com/mac/osx/tools.html
 
 
 
useful.
 
 
 
Ciao
 
/Andreas
 
 
 
 
 
 
 
'''See also:'''
 
* [[Installing Scribus from CVS sources on Mac OS X]] - Howto on installing Scribus from CVS sources through Fink
 
* [[Installing Scribus on Mac OS_X]] - Howto on installing the stable version of Scribus through Fink
 

Latest revision as of 11:34, 12 April 2015

Native version of Scribus for Mac OSX

Stable

  • You can grab the latest stable version of Scribus from here or you can get full installation instructions (including installation of GhostScript) here.

Development

Obsolete

Obsolete PPC OSX

  • Scribus 1.3.x on MacOSX is still work in progress, but there are very usable, frequently updated binary test builds. Details are here http://www.scribus.net/?q=macosx
  • Builds of the native Aqua version are now available from sourceforge (choose the 1.3.5svn version)
  • aqua.scribus.net is the place go for the native Aqua version, when you want to know more details and download the latest packages (but this link now seems to redirect to a general page)
  • List of all known issues — check this list before reporting new errors