[scribus] running Scribus on eeePC
Robert Marma
robert_marma at yahoo.com
Wed Aug 12 06:50:01 CEST 2009
Just like Patrick Ernst, I, too, have an Asus eeePC, and was wondering how well Scribus will run on it. Can I safely install Scribus without any problems? I would appreciate advice from Patrick or anyone out there.
Thank you.
--- On Mon, 8/10/09, scribus-request at lists.scribus.net <scribus-request at lists.scribus.net> wrote:
> From: scribus-request at lists.scribus.net <scribus-request at lists.scribus.net>
> Subject: scribus Digest, Vol 17, Issue 25
> To: scribus at lists.scribus.net
> Date: Monday, August 10, 2009, 12:14 PM
> Send scribus mailing list submissions
> to
> scribus at lists.scribus.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.scribus.net/mailman/listinfo/scribus
> or, via email, send a message with subject or body 'help'
> to
> scribus-request at lists.scribus.net
>
> You can reach the person managing the list at
> scribus-owner at lists.scribus.net
>
> When replying, please edit your Subject line so it is more
> specific
> than "Re: Contents of scribus digest..."
>
>
> Today's Topics:
>
> 1. Re: workaround for
> bigger-than-screen Preferences dialog
> (Patrick Ernst)
> 2. Re: Kerning with combining
> diacriticals (Pierre Marchand)
> 3. Re: workaround for
> bigger-than-screen Preferences dialog
> (Fritz Eichelhardt)
> 4. Re: Scribus Limits, Present and
> Future (John Beardmore)
> 5. Re: Scribus Limits, Present and
> Future (John Jason Jordan)
> 6. Re: Kerning with combining
> diacriticals (John Jason Jordan)
> 7. Re: Scribus Limits, Present and
> Future (John Beardmore)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 10 Aug 2009 21:49:25 +0930
> From: Patrick Ernst <patrick at aroaustralia.com>
> Subject: Re: [scribus] workaround for bigger-than-screen
> Preferences
> dialog
> To: Scribus User Mailing List <scribus at lists.scribus.net>
> Message-ID: <4A80104D.1040309 at aroaustralia.com>
> Content-Type: text/plain; charset=us-ascii
>
> It can be useful to use Alt-Left-click and hold, then drag
> the window
> up, so you can see the bottom of the dialogue. But I agree,
> it would be
> great if the dialogues could fit to any screen size. My
> eeePC is
> 800x480, so I often lose the bottoms of dialogues until I
> move them upwards.
>
> Patrick
>
> Gregory Pittman wrote:
> > I recently bought a netbook (Dell 2100 N), which I
> would advise anyone
> > considering a netbook to consider. First of all, an
> option is to have
> > it come with Ubuntu pre-installed. The main value to
> me is that I
> > immediately know that at least _some_ version of Linux
> will manage the
> > hardware issues. Without getting into any
> distro-bashing, I'll just go
> > on to say that as soon as I could, I replaced Ubuntu
> with Fedora 11,
> > mainly because I'm more comfortable with it, and have
> lots of
> > experience compiling Scribus on Fedora. [One of the
> lame things about
> > this factory-installed Ubuntu is that you lose >5GB
> of your 16GB SSD
> > to a vfat "rescue partition", which, if you booted
> into by mistake or
> > on purpose, would completely blow away any data you
> might have saved
> > in Ubuntu and restore you to a pristine
> factory-installed state. (ie,
> > Dell-Linux for Dummies)]
> >
> > Ok, getting back to this list, once I had Fedora, then
> I knew all
> > about SVN and cmake and compiling Scribus. Everything
> went well until
> > I opened File > Preferences, and noted that the
> Preferences dialog
> > ends up being taller than the 576 pixels this netbook
> can manage. The
> > problem this causes is that you might be able to make
> various changes
> > in your Preferences, but how do you save them?
> Eventually I figured
> > out that I could make changes, then press Alt+O as an
> equivalent for
> > the Ok button. I would add at this point that, in
> contrast to some
> > other apps with this problem, you cannot Tab to the
> offscreen Ok
> > button -- it seems to get stuck at the first offscreen
> button,
> > regardless of whether you're doing Tab or Shift+Tab.
> >
> > The Solution:
> > Eventually, with some playing around that many of us
> Linux users are
> > prone to, I can report that, at least with Fedora 11
> and KDE, if you
> > click on the little icon in the upperleft part of the
> title bar, you
> > can then select Advanced > Special Window Settings,
> where you can
> > check the Size checkbox, THEN click the drop down list
> that says Do
> > Not Affect, where you can click on an item Force. NOW
> you can change
> > the settings, which for my computer specified a height
> of 683 pixels,
> > to something that is somewhere onscreen. Note that
> once you do this,
> > after you click Apply, Click Ok in the Advanced
> Settings dialog, you
> > must Quit and restart Scribus to check out your
> changes.
> >
> > This is not the total solution. What you will find in
> the dialog is
> > that some tabs contain more lines of text than will
> fit in the newly
> > shrunken dialog. In addition, no slider appears to
> allow access to the
> > missing information. So in the General tab, you must
> reduce the size
> > of the font, more specifically Font Size (Menus) so
> that everything
> > fits in the dialog (I can manage 6-7 points). Click
> Apply and you see
> > your result onscreen. I would add that changing the
> font size does not
> > affect the dialog size, in case you wondered.
> >
> > Having gone through all this, my suspicion is that an
> alternative
> > approach is somewhere in the bowels of Qt -- at least
> it seems
> > sensible that Qt should be paying attention to my
> display settings. If
> > I figure this out I will post an update.
> >
> > Greg
> >
> >
> > _______________________________________________
> > scribus mailing list
> > scribus at lists.scribus.net
> > http://lists.scribus.net/mailman/listinfo/scribus
> >
>
>
> --
> Patrick Ernst
> ARO Australia Pty Ltd
> Mob: 0404 883 145
> Fax: 08 8219 0124
> iNet: www.aroaustralia.com
>
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 10 Aug 2009 14:27:55 +0200
> From: Pierre Marchand <capparis at free.fr>
> Subject: Re: [scribus] Kerning with combining diacriticals
> To: scribus at lists.scribus.net
> Message-ID: <200908101427.56317.capparis at free.fr>
> Content-Type: Text/Plain; charset="iso-8859-1"
>
> Vous (John Jason Jordan) avez ?crit :
> > Using 1.3.5 Rc3 on Jaunty.
> >
> > I do work in linguistics which requires frequent use
> of combining
> > diacriticals. Unfortunately, the combining
> diacriticals are spaced so
> > they are pretty well centered on letters like n or x,
> but not on a thin
> > letter like an l or a thick letter like an m. To see
> what I am talking
> > about. type "l n m" and after each enter the combining
> diacritic for
> > voiceless, which is Unicode 325. If no diacritic
> appears switch to a
> > font that has combining diacriticals. The voiceless
> character is a
> > small circle that should appear centered under the
> letter.
> >
> > If you followed me so far you should see that the
> circle is centered
> > under the n, but not under the l or the m.
> >
> > If I am just doing a quick and dirty term paper I
> don't care. But when
> > I am preparing a book that I intend to sell I want
> perfection. I can
> > kern the character using Story Editor so the diacritic
> is perfectly
> > centered, but then the letter and its combining
> diacritic are both
> > kerned so they appear incorrect next to adjacent
> letters.
> >
> > As an exercise to see what I am talking about, type
> "plosive" and put a
> > voiceless diacritic under the l. Now kern the
> diacritic and the l so
> > the diacritic is centered (about -8% should do it).
> The diacritic will
> > be centered, but the l will suddenly be spaced too far
> from the p. That
> > is because to select the diacritic you also have to
> select the l.
> >
> > I've tried everything I can think of, but I can't get
> it to work right.
> > Does anyone have any suggestions?
>
> Composite glyphs are well composed by means of mark
> to mark (mkmk)
> positioning feature, which Scribus does not support atm.
> Your best chance is
> to get a font having all glyphs you need accessible through
> the regular
> Unicode cmap.
>
> hth
>
> --
> Pierre Marchand
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 10 Aug 2009 14:55:15 +0200
> From: Fritz Eichelhardt <f.eichelhardt at web.de>
> Subject: Re: [scribus] workaround for bigger-than-screen
> Preferences
> dialog
> To: scribus at lists.scribus.net
> Message-ID: <200908101455.15523.f.eichelhardt at web.de>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> > From: Gregory Pittman <gregp_ky at yahoo.com>
>
> > the Preferences dialog ends up being
> > taller than the 576 pixels this netbook can manage
> > The problem this
> > causes is that you might be able to make various
> changes in your
> > Preferences, but how do you save them?
>
> why don't you just move the window with
>
> <ALT> + mouse-moving anywhere in the
> preference-window.
>
> working here with suse-linux.
> should work on any linux-system.
>
> --
> Mit freundlichen Gr??en
>
> Fritz Eichelhardt
> Br?ckenstr. 1
> 53545 Linz
> Tel.: 02644 - 3784
> Fax/UMS: 01212 - 517045068
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 10 Aug 2009 14:04:22 +0100
> From: John Beardmore <John at T4sLtd.co.uk>
> Subject: Re: [scribus] Scribus Limits, Present and Future
> To: Scribus User Mailing List <scribus at lists.scribus.net>
> Message-ID: <4A801AD6.8020001 at T4sLtd.co.uk>
> Content-Type: text/plain; charset=ISO-8859-1;
> format=flowed
>
> John Jason Jordan wrote:
> > On Fri, 7 Aug 2009 11:45:01 -0400
> > John Morris <johnjeff at editide.us>
> dijo:
>
> > This is the first long document I have done in
> Scribus. In the past I
> > have done textbooks in InDesign on Windows 2000, up to
> 550 pages.
> > InDesign ran as fast with a 550 page document open as
> it did with a one
> > page document open. I have also used PageMaker,
> QuarkXPress and Venture
> > previously and never had an issue about slow speed
> when working on long
> > documents.
>
> When I began using Pagemaker 6.5 I had a real quick machine
> which was a
> 200MHz pentium. That seemed to slow down as the number of
> pages
> increased, but that may be because it only had 256 meg of
> RAM.
>
> In the end I moved some of our work to InDesign 1.5, but
> neither that or
> Pagemaker were that stable or good at generating high
> resolution PDFs,
> even with documents of 30 to 40 pages. Given the costs of
> upgrading to
> CS*, we didn't / couldn't / wouldn't. Those stability
> issues have not
> gone away on modern machines, so I guess they were bugs /
> design
> failings rather than machine resource issues. they may have
> been
> addressed in later versions of the software I guess, but at
> Adobe
> prices, I really resent having to upgrade just to get
> software that
> doesn't crash !
>
> Except in respect of WISIWYG in text frame editing, Scribus
> to date has
> been massively superior to either of those, certainly with
> documents of
> 60 to 70 pages. It really would be good to know what makes
> Scribus slow
> down in big documents and assay what various people have
> managed easily
> / got away with.
>
> I suppose until 1.3.5 is released, there isn't much point
> in comparing
> experiences in detail, but maybe once 1.3.5 is out we
> should all
> contribute the following information for our larger
> projects ?
>
> Processor
> RAM
> Document number pages
> Page size
> Average number of linked text
> frames
> Maximum number of linked text
> frames
> Numbers of characters in linked
> text frapmes
> Which operations in Scribus are
> least responsive
>
>
> This isn't an issue that's going to go away. Every new user
> seems to ask
> it / be concerned about it, and the more precise the
> answers we can
> give, the better prospective users can decide if Scribus
> does what we need.
>
> I appreciate all of the above are rather clumsy metrics and
> somewhat
> subjective, better suggestions welcome ! But they are
> possibly better
> than the indicators we can generally offer at the moment,
> which are
> generally "large", or on a good day, a number of pages of
> unspecified size.
>
>
> Cheers, J/.
> --
> John Beardmore, MSc EDM (Open), B.A. Chem (Oxon), CMIOSH,
> AIEMA, MEI
> Managing Director, T4 Sustainability Limited. http://www.T4sLtd.co.uk/
> Energy Audit, Carbon Management, Design Advice, Sustainable
> Energy
> Consultancy and Installation, Carbon Trust Standard
> Registered Assessor
> Phone: 0845 4561332 Mobile: 07785
> 563116 Skype: t4sustainability
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 10 Aug 2009 07:36:34 -0700
> From: John Jason Jordan <johnxj at comcast.net>
> Subject: Re: [scribus] Scribus Limits, Present and Future
> To: scribus at lists.scribus.net
> Message-ID: <20090810073634.1f811f61.johnxj at comcast.net>
> Content-Type: text/plain; charset=US-ASCII
>
> On Mon, 10 Aug 2009 14:04:22 +0100
> John Beardmore <John at T4sLtd.co.uk>
> dijo:
>
> > John Jason Jordan wrote:
> > > On Fri, 7 Aug 2009 11:45:01 -0400
> > > John Morris <johnjeff at editide.us>
> dijo:
> >
> > > This is the first long document I have done in
> Scribus. In the past I
> > > have done textbooks in InDesign on Windows 2000,
> up to 550 pages.
> > > InDesign ran as fast with a 550 page document
> open as it did with a one
> > > page document open. I have also used PageMaker,
> QuarkXPress and Ventura
> > > previously and never had an issue about slow
> speed when working on long
> > > documents.
>
> > It really would be good to know what makes Scribus
> slow
> > down in big documents and assay what various people
> have managed easily
> > / got away with.
> >
> > I suppose until 1.3.5 is released, there isn't much
> point in comparing
> > experiences in detail, but maybe once 1.3.5 is out we
> should all
> > contribute the following information for our larger
> projects ?
> >
> > Processor
> > RAM
> > Document number pages
> > Page size
> > Average number of linked text
> frames
> > Maximum number of linked text
> frames
> > Numbers of characters in linked
> text frapmes
> > Which operations in Scribus are
> least responsive
> >
> > This isn't an issue that's going to go away. Every new
> user seems to ask
> > it / be concerned about it, and the more precise the
> answers we can
> > give, the better prospective users can decide if
> Scribus does what we need.
> >
> > I appreciate all of the above are rather clumsy
> metrics and somewhat
> > subjective, better suggestions welcome ! But
> they are possibly better
> > than the indicators we can generally offer at the
> moment, which are
> > generally "large", or on a good day, a number of pages
> of unspecified size.
>
> First, I didn't mean to sound as though I am dissatisfied
> with Scribus.
> Just the opposite - I love it. It's just that all I do are
> textbooks,
> so speed with long documents is more important to me than
> it might be
> for some users.
>
> The document I am working on at the moment is 120 pages
> with lots of
> vector graphics and text frames. But there are no text
> frame threads
> that go more than five or six frames, and there are no
> bitmaps. It is
> painfully slow, but I have found that learning and using
> keyboard
> shortcuts is some help. For example, if I deselect an
> object by
> clicking elsewhere on the canvas it takes ~15 seconds for
> the object to
> become deselected, but if I do Ctrl-Shift-a the object is
> deselected
> instantly. Similarly, right-clicking on a text frame to get
> the context
> menu and then selecting Edit Text it takes 5-10 seconds for
> the context
> menu to come up. But if I do Ctrl-y the Story Editor
> launches right
> away (although it still takes several seconds before it is
> ready). Just
> about every mouse action is slow, yet if I can use a
> keyboard shortcut
> the action happens instantly.
>
> It would be nice if, once 1.3.5 is final, we can sit back
> and polish it
> up before plunging forward with new feature development for
> the next
> version. It's not just the speed issue - there are quite a
> few rough
> edges that are not show stoppers but could stand
> improvement.
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 10 Aug 2009 07:57:25 -0700
> From: John Jason Jordan <johnxj at comcast.net>
> Subject: Re: [scribus] Kerning with combining diacriticals
> To: scribus at lists.scribus.net
> Message-ID: <20090810075725.bdf88135.johnxj at comcast.net>
> Content-Type: text/plain; charset=UTF-8
>
> On Mon, 10 Aug 2009 14:27:55 +0200
> Pierre Marchand <capparis at free.fr>
> dijo:
>
> > Vous (John Jason Jordan) avez ?crit :
> > > Using 1.3.5 Rc3 on Jaunty.
> > >
> > > I do work in linguistics which requires frequent
> use of combining
> > > diacriticals. Unfortunately, the combining
> diacriticals are spaced so
> > > they are pretty well centered on letters like n
> or x, but not on a thin
> > > letter like an l or a thick letter like an m. To
> see what I am talking
> > > about. type "l n m" and after each enter the
> combining diacritic for
> > > voiceless, which is Unicode 325. If no diacritic
> appears switch to a
> > > font that has combining diacriticals. The
> voiceless character is a
> > > small circle that should appear centered under
> the letter.
> > >
> > > If you followed me so far you should see that the
> circle is centered
> > > under the n, but not under the l or the m.
> > >
> > > If I am just doing a quick and dirty term paper I
> don't care. But when
> > > I am preparing a book that I intend to sell I
> want perfection. I can
> > > kern the character using Story Editor so the
> diacritic is perfectly
> > > centered, but then the letter and its combining
> diacritic are both
> > > kerned so they appear incorrect next to adjacent
> letters.
> > >
> > > As an exercise to see what I am talking about,
> type "plosive" and put a
> > > voiceless diacritic under the l. Now kern the
> diacritic and the l so
> > > the diacritic is centered (about -8% should do
> it). The diacritic will
> > > be centered, but the l will suddenly be spaced
> too far from the p. That
> > > is because to select the diacritic you also have
> to select the l.
> > >
> > > I've tried everything I can think of, but I can't
> get it to work right.
> > > Does anyone have any suggestions?
> >
> > Composite glyphs are well composed by means of
> mark to mark (mkmk)
> > positioning feature, which Scribus does not support
> atm. Your best chance is
> > to get a font having all glyphs you need accessible
> through the regular
> > Unicode cmap.
>
> Unfortunately, such a font does not exist.
>
> There is a PDF here which shows all the diacritics that I
> need:
>
> http://www.langsci.ucl.ac.uk/ipa/fullchart.html
>
> I have several fonts that have all the combining
> diacritics. Using the
> diacritics I can create any character. But for a font to
> contain every
> possibility as individual glyphs would exceed the number of
> slots
> available in Unicode. Even if such a font existed it would
> be
> impossible to locate the individual glyph you need.
>
> I need to study more how composite glyphs work. Maybe I can
> figure out
> a workaround.
>
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 10 Aug 2009 17:14:16 +0100
> From: John Beardmore <John at T4sLtd.co.uk>
> Subject: Re: [scribus] Scribus Limits, Present and Future
> To: Scribus User Mailing List <scribus at lists.scribus.net>
> Message-ID: <4A804758.8010500 at T4sLtd.co.uk>
> Content-Type: text/plain; charset=ISO-8859-1;
> format=flowed
>
> John Jason Jordan wrote:
> > On Mon, 10 Aug 2009 14:04:22 +0100
> > John Beardmore <John at T4sLtd.co.uk>
> dijo:
> >
> >> John Jason Jordan wrote:
> >>> On Fri, 7 Aug 2009 11:45:01 -0400
> >>> John Morris <johnjeff at editide.us>
> dijo:
> >>> This is the first long document I have done in
> Scribus. In the past I
> >>> have done textbooks in InDesign on Windows
> 2000, up to 550 pages.
> >>> InDesign ran as fast with a 550 page document
> open as it did with a one
> >>> page document open. I have also used
> PageMaker, QuarkXPress and Ventura
> >>> previously and never had an issue about slow
> speed when working on long
> >>> documents.
> >
> >> It really would be good to know what makes Scribus
> slow
> >> down in big documents and assay what various
> people have managed easily
> >> / got away with.
> >>
> >> I suppose until 1.3.5 is released, there isn't
> much point in comparing
> >> experiences in detail, but maybe once 1.3.5 is out
> we should all
> >> contribute the following information for our
> larger projects ?
> >>
> >> Processor
> >> RAM
> >> Document number pages
> >> Page size
> >> Average number of linked text
> frames
> >> Maximum number of linked text
> frames
> >> Numbers of characters in
> linked text frapmes
> >> Which operations in Scribus
> are least responsive
> >>
> >> This isn't an issue that's going to go away. Every
> new user seems to ask
> >> it / be concerned about it, and the more precise
> the answers we can
> >> give, the better prospective users can decide if
> Scribus does what we need.
> >>
> >> I appreciate all of the above are rather clumsy
> metrics and somewhat
> >> subjective, better suggestions welcome ! But
> they are possibly better
> >> than the indicators we can generally offer at the
> moment, which are
> >> generally "large", or on a good day, a number of
> pages of unspecified size.
> >
> > First, I didn't mean to sound as though I am
> dissatisfied with Scribus.
> > Just the opposite - I love it. It's just that all I do
> are textbooks,
> > so speed with long documents is more important to me
> than it might be
> > for some users.
> >
> > The document I am working on at the moment is 120
> pages with lots of
> > vector graphics and text frames. But there are no text
> frame threads
> > that go more than five or six frames, and there are no
> bitmaps. It is
> > painfully slow, but I have found that learning and
> using keyboard
> > shortcuts is some help. For example, if I deselect an
> object by
> > clicking elsewhere on the canvas it takes ~15 seconds
> for the object to
> > become deselected, but if I do Ctrl-Shift-a the object
> is deselected
> > instantly. Similarly, right-clicking on a text frame
> to get the context
> > menu and then selecting Edit Text it takes 5-10
> seconds for the context
> > menu to come up. But if I do Ctrl-y the Story Editor
> launches right
> > away (although it still takes several seconds before
> it is ready). Just
> > about every mouse action is slow, yet if I can use a
> keyboard shortcut
> > the action happens instantly.
>
> OK - I'm not a Scribus developer, but if I were, I
> imagine that would
> give me some clues.
>
> If the problem lurks with the innards of Qt there may not
> be much they
> can do about it I guess, but at least using the keyboard
> short cuts can
> be made known as a quicker way to navigate around Scribus.
>
> Out of interest, in terms of the check list I suggested
> above, what are
> you using ?
>
> I've lurked on this list for couple of years and I think
> it's the first
> time I've seen this described. It's good to know.
>
>
> > It would be nice if, once 1.3.5 is final, we can sit
> back and polish it
> > up before plunging forward with new feature
> development for the next
> > version. It's not just the speed issue - there are
> quite a few rough
> > edges that are not show stoppers but could stand
> improvement.
>
> Not my call, but the developers seem to have a very sound
> approach.
>
>
> Cheers, J/.
> --
> John Beardmore, MSc EDM (Open), B.A. Chem (Oxon), CMIOSH,
> AIEMA, MEI
> Managing Director, T4 Sustainability Limited. http://www.T4sLtd.co.uk/
> Energy Audit, Carbon Management, Design Advice, Sustainable
> Energy
> Consultancy and Installation, Carbon Trust Standard
> Registered Assessor
> Phone: 0845 4561332 Mobile: 07785
> 563116 Skype: t4sustainability
>
>
>
> ------------------------------
>
> _______________________________________________
> scribus mailing list
> scribus at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus
>
>
> End of scribus Digest, Vol 17, Issue 25
> ***************************************
>
More information about the scribus
mailing list