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.info <scribus-request at lists.scribus.info> wrote: > From: scribus-request at lists.scribus.info <scribus-request at > lists.scribus.info> > Subject: scribus Digest, Vol 17, Issue 25 > To: scribus at lists.scribus.info > Date: Monday, August 10, 2009, 12:14 PM > Send scribus mailing list submissions > to > ??? scribus at lists.scribus.info > > To subscribe or unsubscribe via the World Wide Web, visit > ??? http://lists.scribus.info/mailman/listinfo/scribus > or, via email, send a message with subject or body 'help' > to > ??? scribus-request at lists.scribus.info > > You can reach the person managing the list at > ??? scribus-owner at lists.scribus.info > > 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.info> > 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.info > > http://lists.scribus.info/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.info > 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.info > 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.info> > 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.info > 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.info > 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.info> > 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.info > http://lists.scribus.info/mailman/listinfo/scribus > > > End of scribus Digest, Vol 17, Issue 25 > *************************************** >
