Recent Posts

Pages: 1 2 3 4 [5] 6 7 8 9 10
Text and Typography / Re: Italic update?
« Last post by JohnJR on March 23, 2017, 11:27:56 pm »
Hi Folks,

So all the fonts given me in either Fonts Preview or Properties Palette don't reside anywhere in Scribus itself but only reflect what Mr. and Mrs. Apple have handed me?

Back to Yikes!  If that's all I get, there is still more exploring than I'm likely to do in a lifetime.  If I have two or three days, or a new need, I'll look at what's been given to me first.  However I appreciate all your suggestions and I bet some of them show example alphabets right along side the font names, just like the old font books I first had in college five decades ago.

Text and Typography / Re: Importing .docx or .pages files in Scribus 1.4.6?
« Last post by JohnJR on March 23, 2017, 10:55:56 pm »
Hi Utnik,

So the numbering and header text are setup on/as a new (or should I say additional) pair of master pages, titled "Numbers" (L and R).

Whether I did this correctly or not, in one sense it does seem somehow I did join two sets of master pages: Two Normal's and two Number's to document pages 10-48.  Document Pages 10-48 now appears exactly as intended.  Not knowing any better at the time layering these two sets respectively, L and R, was what I intended to do.  I don't understand, or should I be concerned, why Normal Right is "unused"; it appears as it should with properly formatted text throughout the book.  Maybe I should have named the two new master pages "Header" L an R instead of "Numbers".

Touching on why the wacky numbers show up on document pages 3-9, (I thought all pages had to be accounted for, I was using the zero in "start" to represent none--empty).  With neither header text frame showing then I didn't see that as a concern, the result is what I intended--blank headers.  And initially it stayed that way though a couple of saves and closes.

Out of the blue, on document pages 3-9 the "Numbers" master pages (both header text frames) showed up where they were never applied.  Studying your suggestions, I found the wacky pagination made sense, but why had it suddenly appeared where it was never applied?

The "show" box in Sections had checked itself.  So I'll just un-check "show" again, click Apply and Okay.  They were still there.  I went back into Sections and the "show" box had checked itself again: un-checked again, Apply Okay again; still there again.  It became a loop.  Finally I just deleted the first pagination row in its entirety hoping the remaining row wouldn't jump up and populate document pages 1-9, let alone page 3.  It didn't.  Document pages 10-48 remain as intended.

However only the pagination disappeared (as intended).  The other header text frame still remains with its text visible in document pages 3-9.  Page > Apply Master Pages and re-entering the specified document page range 10,11-47,48 for "Numbers" L and R does nothing to change this for document pages 1-9

You will be relieved to know I did find a solution, unless I didn't find a solution I guess.  I went back into Page > Apply Master Pages and re-applied the Normal L and R pages to the document page range 1-9 and clicked Okay.  The offending header text was gone, greyed out header text frames, and both empty.  Crossing my fingers, I exported the document using the holy grail PDF-x-1a.  The pdf looks perfect, cross your fingers.  Maybe I can stay out of your hair for a while.

I note that on about March 13th the discussion matter veered far from the original subject title (importing .docx etc.) into the world of Master Pages.  Any lessons learned through Master Page fiascos might not show up to other pilgrims searching for similar enlightenment.  Can you--or is there a set procedure for--moving the portion of this thread dealing with Master Pages to a place where it finds more daylight to those experiencing similar Master Page issues?

Linux / Re: Can't install templates (1.4.6 on Lubuntu)
« Last post by Leonard03 on March 23, 2017, 08:55:04 pm »
hi leonard

…I doubt they would have made them with the developmental branch.

you can check this when you open one of the files with a text editor. you find the scribus version in the second line.

You're bang on the money sir. Looks like they used 1.5.1

Thanks for the help you guys!
User Interface / Re: The context menu
« Last post by CGood on March 23, 2017, 03:18:45 pm »
A quick reply:

I like GarryP's context menu concept.

I'd add the Levels (up down top bottom) to his lists.

In the more distant future I'd love to see the ability for the user to be able to add or remove items from context menus etc., but that feels like several steps down the road.
User Interface / Re: The context menu
« Last post by GarryP on March 23, 2017, 02:48:01 pm »
Thinking back a bit on my own use of the context menu:
* Firefox - "Bookmark" and various "Save" functions, sometimes "View Page Source";
* GIMP - only really use it in the Layers toolbox for things like "Add Layer Mask" and "Merge Down", can't remember the last time I used it over an image;
* Inkscape - very rare, can't remember using it (have just been in to see what it looks like);
* Notepad++ - "Select All" and "Copy" normally one straight after the other, and spell check.

If I had to choose a most-used sub-set of actions for the Scribus context menu it might be something like:


* Get Text
* Edit Text
* Sample Text
* Send To Layer
* Convert To
* Edit Shape (open Node Editor)


* Get Image
* Adjust Image to Frame
* Adjust Frame to Image
* Update Image (not entirely necessary)
* Image Effects
* Preview Settings
* Send To Layer
* Convert To
* Edit Shape (open Node Editor)
* Text Flow Around (with options)

POLYGON (and most others)

* Send To Layer
* Convert To
* Edit Shape (open Node Editor)
* Text Flow Around (with options)
User Interface / Re: The context menu
« Last post by a.l.e on March 22, 2017, 04:11:12 pm »
A complement to my question: What are you using the context menu for?

I use it:

- in Firefox for starting the inspector on a specific item (otherwise it's F12)
- in Irc to leave channels (right click on a specific channel and leave it)
- In Firefox / Libreoffice / Email to pick a spelling correction
- In Gimp to crop and resize images
- In Scribus for sending items to specific layers (I miss the action in Inkscape)
- In Scribus for fitting a frame to the image (but not the image to the frame)

Those are tasks that are highly related with a visual element I see on screen.

Personally, I'd wish that Scribus would have only few action in the context menu, mostly without sub menus.
Highly context sensitive.
Fast to trigger.

And use other means for making the available actions discoverable.
User Interface / Re: The context menu
« Last post by GarryP on March 22, 2017, 02:34:17 pm »
If we think about what the context menu is called then there is the argument that its contents should relate to the object that has been right-clicked. In other words, the context menu should - using this argument - only hold actions that are relevant within the "context" of that object. To say it a bit differently, the context menu should only show actions that can be applied to the object that is selected.

For instance, if you right-click on an image frame then - using the above argument - there should only be actions in the context menu that can be applied to an image frame. That's a pretty reasonable argument but there's a slight problem: What about actions that are relevant to the context but are currently either not available or not applicable?

To expand the above scenario, if you right-click on an image frame you get a list of actions that relate to that frame - all well and good so far - but you may also get some actions that are not actually applicable. For instance, there's currently an action for "Adjust Image to Frame". This action is always available, even if the action has just been applied and the image already fits the frame. Using the argument above, this action should not be available as there is no reason to fit the image to the frame again; it's a pointless action - at this moment - because it has no effect. (The same goes for "Level -> Raise" when the object is at the top of the stack. etc.)

So now we have the question of what to do with this action. Should it be greyed out - to show the user that it might become available in the future - or should it not appear in the menu until it can be applied?

There is an argument that the action should not appear because it can't be applied and having it there takes up valuable space forcing the user to mouse over it to get to other actions. There is also the counter-argument that the action should appear - but be greyed out - so that the user knows that it's a possible action but it's just not available at the moment.

The discussion about which argument is correct has gone on for decades and will probably never conclude satisfactorily to both sides but it leads me to the next point: You either clamp down on the available actions and only show those that can be applied at the moment in time the user right-clicks, or you show more actions than those which are applicable. If you show more, then how many more do you show? Who decides which are to be shown and how far do you go?

As has already been mentioned, some applications - like GIMP - offer the user all possible actions but some are greyed out and unavailable. This means that you have a very large context menu with a lot of potential actions which the user can browse through to see if they can find one they want to use. This can be very useful to casual users where they know they did something a while back that performed the action they wanted but they can't quite remember what it was called. On the other hand, it can mean that the user is shown a multitude of choices, some of which are not available and they don't know how to make them available, and that can be frustrating.

Personally, I think that the main menu should offer every possible action - with some greyed out if they are not currently available - and the context menu should only offer those actions that can be currently applied within the context of the object that has been right-clicked. (By way of example, Scribus already does this by not showing the "Adjust Image to Frame" action if an image frame has no image.) I think this is a reasonable compromise between the two arguments. People who want to see every possible action - even if they can't actually preform them at the time - can see them through the main menu and people who only want to see the actions they can currently perform can use the context menu.

To expand on that a little: There also should be no action available via the context menu that isn't also available via the main menu. To rephrase that, there should be no actions that are "hidden" in the contextual menu. There are some people who don't use the contextual menus. There could be many reasons for this: they are using a pointing device that only has one button; they have limited physical ability and cannot use more than one button; etc. These people should not be given a worse experience of using the software because they cannot access part of it.

Then there is then the argument between having a "long" context menu and having a hierarchical context menu. Again, the arguments about this have been going on for decades and there is no "correct" answer. Some people like to have everything available on the first level of the menu while others prefer a shorter menu with sub-levels. I have used some applications where a long single-level menu is good and I have used some applications where a multi-level menu is good. It really depends on the application.

I think Scribus 1.4.6 has a decent compromise between the two. For instance, I like to be able to get to "Adjust Image to Frame" straight from the root level of the menu rather than having to go through something like "Image -> Adjustments -> Adjust Image to Frame". Conversely, I prefer to use "Level -> Raise" rather than having the Raise, Lower, Raise to Top and Lower to Bottom actions all in the root level. And when you consider the "Send To Layer" actions that makes even more sense.

As for which actions should be in the context menu and where they should be in it, I don't think anyone is going to agree with anyone else on everything. For me, having "Info" as the first action isn't very useful. I hardly ever use that function and having to mouse over it every time makes the menu feel awkward. The same goes for the Undo function (I generally use CTRL+Z). I also use "Send to Layer" much more often than I use "Edit Image" or "Attributes". But that's just me, other people might use Scribus differently. I don't think there will be consensus on this.

In summary then, I think that:
* The main menu should show all possible actions - even if they're not currently available.
* The context menu should only show actions that are applicable to the object currently selected.
* The context menu should present a compromise between a single-level list and a hierarchical list.

I realise that this doesn't answer a lot of questions but I hope I've been able to explain some reasoning in a decent way that helps the discussion move forward.
Text and Typography / Re: Importing .docx or .pages files in Scribus 1.4.6?
« Last post by utnik on March 22, 2017, 07:11:22 am »
hi john

yes, that's different from the file you uploaded before:
  • now there are four master pages – but of course not two of them applied to the same document page, as this is not possible… (three of them are used in the document, 'normal right' is unused so far.)
  • and there are two sections
Your assumptions from the beginning that those originals had only the margin-defined text box set up at that point

no, these boxes aren't on any master page. when creating a new document, you can tell scribus to apply a chain of linked margin sized text boxes across all pages of the document – independent of the master pages. that's where they went from.

…also note the pagination reverses itself, left odd right even…

again, it's not something scribus does wrong.
you should be more careful when experimenting with functions which are new for you!
in the 'sections' tab of 'document setup' you told scribus to start the numbering in the first section (pages 1-9) with '0' – so scribus does it's job well and marks page 1 as '0', page 2 as '1', page 3 as '2', and so on.
as all the left pages in this section and te first page are based on 'normal left', they don't show any page numbers.
but all the right pages aof the whole document (except the first one) are based on 'number right' and show page numbers based on the counting and formatting scheme you defined in the 'sections' tab.

Text and Typography / Re: Importing .docx or .pages files in Scribus 1.4.6?
« Last post by JohnJR on March 22, 2017, 01:37:28 am »
Hi Utnik,

I checked here and there should be four Master Pages.  The default Normal Left and Right Master Pages I originally used to construct the entire book.  Your assumptions from the beginning that those originals had only the margin-defined text box set up at that point, while I added the header and page number text boxes to those two in Document Set Up later.  When I applied those two Master Pages, only the margin-defined text box would activate, the two header boxes remained mute, just grey outlines.

That is when I thought I was doing the right thing by creating two new Master Pages via Edit > Master Pages.  These two new Master Pages are named "Numbers Left" and "Numbers Right" and are listed as such at my end.  The two new Master Pages were created from the original Normal Left and Right by applying text frames to the two header boxes greyed out on those and adding repetitive text and pagination place holders two those header text boxes.

In that sense maybe they are not stand alone Master Pages in their own right but somehow only derivatives of the two originals.  Could that be why they might not show as Master Pages in there own right--named as such?  And perhaps acting now like such renegades?

After all, I applied these two "Numbers" Pages By defining pagination for them and then what I thought was correct; applying them over the original Pages for the specified pagination and it worked.  I thought the manuscript was done, saved.  But opening it up, originally had only the two pages at the end that just needed deleting.  (Thanks for the tip: Pages > Delete I was highlighting the pages and trying to use my delete-key.  There was na-da I could find in help forums about that simple sequence.)

Upon opening the file for the second time, that is when the rogue new "Numbers" Masters Pages populated themselves where they were never applied to: document pages 3-9 (title page through first chapter page, also note the pagination reverses itself, left odd right even while the text remains correct) with page numbers commencing with 2 and going thru 8.  Beginning with document page 10 (numbered as 2) both header text boxes are applied correctly as specified to document page 48 (page number 40).  As I said, Page > Apply and re-applying the Numbers Pages does nothing to eliminate the initial header wackiness up to document page page 9.

I've saved, closed, and reopened the file enough be fairly confident that the document seems fairly stable and in case something has changed I'm attaching a new zip file again.


User Interface / Re: The context menu
« Last post by tim_occ on March 21, 2017, 08:21:50 pm »

In a classic menu bar you have actions sorted by topics, like Edit, Item, Page, etc.
In a context menu you have actions sorted by item.

I like context menues that give me an idea what I can do with the object. But at these point it should be focus on often used things. A second level is ok to group some actions into one topic. What I don't like is an overloaded one-level-menu which is like a wall of text.

I use context menues for two reasons:
1. to see what I can do
2. as a cheat sheet for action shortcuts

Pages: 1 2 3 4 [5] 6 7 8 9 10