Recent Posts

Pages: 1 2 3 4 5 [6] 7 8 9 10
User Interface / Re: The context menu
« Last post by utnik on March 21, 2017, 07:09:52 pm »
hi ale

good question!

i like to see all the available actions in the current context in the CM.
for this it needs a good tree structure.

for speed i prefere keyboard shortcuts. (the context menu is for actions i don't need as often as i would remember the shortcut – so ultimate speed is secondary, but more keyboard shortcuts are needed…)

User Interface / Re: The context menu
« Last post by CGood on March 21, 2017, 06:16:06 pm »
My immediate responses. I'd like context menus to show a very large proportion of all relevant actions.

I prefer a context menu like in 1.5.1 where there is a tree structure. I think the context menu design in 1.5.1 is better than 1.4.6 for example.

Adding hyperlink to a text via an item or tree branch of items in the context menu seems sensible.

I would add that I'd also like to see more actions accessible via keyboard shortcuts. I suspect that is a topic for a different thread but speed of access to actions is connected to this thread.
User Interface / The context menu
« Last post by a.l.e on March 21, 2017, 05:56:21 pm »
What is the role of the context menu in Scribus?

- Show the most relevant actions in the current context?
- Show all the available actions in the current context?
- Show all the possible actions? (Gimp is doing that)

Once this question is answered, how fast should the context menu be?

- Should it have only (mostly) one level for fast triggering?
- Should it have good tree structure? (like now)

Anybody wants to propose a cocept that could be discussed with the team?
(currently, it seems that anybody can wish something and it will be added...)
(the idea to discuss this came from the discussion on the hyperlinks... where somebody proposed to add them to the context menu...)
Beginner Talk / Re: Backgrounds of transparent images suddenly showing up as white
« Last post by Mapsking on March 21, 2017, 03:04:59 pm »
I've been (an still am) using PDF 1.5, and up until recently, the print preview did not show white backgrounds in Scribus, but now they do.  I'm printing on my HP Laserjet M521nw printer, not sending to a commercial printer, and I export to a .pdf, and use Foxit Reader.  Is that a "good" .pdf program to use?  I wanted to try printing directly from Scribus instead of a .pdf, as it is a three face brochure I've made, and the margins are printing at inconsistent distances from the left to right margin, and I wanted to test to see if it was coming from the /pdf reader, but I think maybe it was because I had two sided printing turned on.
Beginner Talk / Re: Backgrounds of transparent images suddenly showing up as white
« Last post by a.l.e on March 21, 2017, 11:16:38 am »
ah, don't print from scribus, create a pdf and use a (good) pdf reader for printing the pdf.
Beginner Talk / Re: Backgrounds of transparent images suddenly showing up as white
« Last post by a.l.e on March 21, 2017, 11:15:06 am »
which pdf version are you using for the export?

many pdf standards do not support transparencies...

as an example, pdf 1.4 and pdf 1.5 do support them.
but take care: even if those "newer" standards have been around for a long time, your print shop might not accept them or break them.
User Interface / Re: Url & links
« Last post by GarryP on March 21, 2017, 11:04:32 am »

As far as I'm concerned, my comments only pertain to the output that Scribus can currently produce from the latest stable version. I'm only interested in PDF output here.

I agree that just changing the pointer isn't enough to mark a hyperlink. If the author didn't remember where they had created links - or they are getting the document from someone else - they would have to mouse over all of the text to find the links. Links should have some kind of persistent - on-screen, but not in preview mode - visual marking to show the user where they are.


Thanks for clarifying that. There's probably still the issue of URLs that are in the text itself - I.e. "Go to for the latest news" - but that might be taking things a bit too far at the moment.


As I said previously, I would advise against using automatic styles to mark hyperlinks. Doing so would create one of two situations:
1. A single "standard" hyperlink style that was applied to all hyperlinks. This would mean that all hyperlinks were formatted in the same way which would spoil any text that wasn't formatted in the same way as the style. Since hyperlinks can be anywhere in any piece of text - formatted by either styles or not - forcing them to all have the same formatting would not be a good way to go.
2. Multiple hyperlink styles. This would be horrible for both the developer and the user. The developer would have to make sure that Scribus updated the styles on-the-fly to conform to any formatting the user applied to the text and the user would have multiple styles to manage. Again, not a good situation.

This is why I suggested that the "look" of the hyperlinks would not be connected with any formatting that the user could apply. Personally I don't really have a problem with how hyperlinks look, as long as they are visually distinct from other formatting. This could be (see attached examples):
* a box (like I've suggested but I'm thinking that this is a bit too "in your face" now);
* a squiggle under the text (a simple underline may confuse the user if their text is already underlined or they might confuse a link for an underline and try and remove it);
* a little icon next to the text;
* a mixture of two of the above;
* or something else entirely.

As long as it's clear what a hyperlink looks like and it can't be confused with user formatting then that's fine by me.

To the clear: I have no problem with the user creating styles to manually format links but I think it would be a mistake for Scribus to be creating and applying them automatically.

utnik (again):

I think the preflight verifier could be used to highlight:
* hyperlinks that are not manually formatted differently - by either a user style or other formatting - from the rest of the text - e.g. there's a link there but no way for the reader to know about it;
* hyperlinks that have no valid target, e.g. a link was created to a text frame that no longer exists.

I'm not sure what you mean by having "hyperlink areas as part of previously defined ones". I can't remember seeing such an embedded link anywhere, either on the web or in a document. Do you have an example? As I understand it, it would be confusing to the user unless there was a way to show that there were multiple links active in the same bit of text. If absolutely necessary the user could define three links, the outer two to one target and the inner one to another. As you said, I don't think this is a big issue though.
Beginner Talk / Backgrounds of transparent images suddenly showing up as white
« Last post by Mapsking on March 21, 2017, 10:52:35 am »
I have almost finished my project, and suddenly, when I print it, the images show up with a white background, instead of being transparent.  This never used to happen, and I think I accidentally changed some setting, and can't figure out how to revert it back.  I'm using version 1.5.2 on Windows 7 Ultimate, and the images have not changed, and when exporting to .PDF, it will print without the white box.  It does not show up except for the print preview option, and of course, when actually printing.  What other information should I provide?  It is driving me crazy, and hopefully someone can help me figure out what I changed, or more importantly, what to do to get it back to the way it was?
User Interface / Re: Url & links
« Last post by utnik on March 21, 2017, 06:59:54 am »
hi garry

Could you explain what you mean by "unmarked" hyperlinks please? Do you mean URLs in the text that are not formatted as links…


I'm not sure if I like the idea of using automatically applied styles for hyperlinks. Unless Scribus creates the styles on the fly - creating a character style from the formatting of the text and keeping it updated - it would have to apply a default style which will probably not be formatted the same as the rest of the text. The user would then have to go in and change the style formatting to match the text.

as i wrote before, i'm not sure, what's best here.
maybe an automatically applied 'standard link style' (might be marked by something like an underline) – and the 'preflight verifier' would check by default if a link is still formatted by this 'standard link style'…

As for intersections of hyperlinked text, I would say that it might be easier for Scribus to just override anything that already exists.

i'm fine with that, as everything else might be a big deal to implement properly – but i see reasons to have hyperlink areas as part of previously defined ones. (i.e. if the source is a map and you have a link on 'asia', and now you need another one on 'nepal', i would prefere to keep the rest of the first link working…)

User Interface / Re: Url & links
« Last post by CGood on March 20, 2017, 05:51:00 pm »
Just a couple of immediate responses: I like what I'm reading here. I hope and assume it pertains only to Scribus output as a pdf on screen - not as Scribus generating a web page output. I have no interest in the latter.

I don't believe links should usually depend upon a visual change in the pointer upon pointer hover to be recognized. They should usually look distinct. Immediate visual differentiation and recognition makes life easier. A default link character style has appeal - as long as the link character style can be modified and made appropriate to the user's needs.

But then I have just opened the doors to making this a more involved project. But as long as I'm writing, should a link be created, in a perfect world it should have a style applied. But in this real world a character style could be manually applied and thus one could control all links with character styles.
Pages: 1 2 3 4 5 [6] 7 8 9 10