View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0014263 | Scribus | Styles | public | 2016-08-14 04:40 | 2016-08-18 21:19 |
| Reporter | kael | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| OS | Ubuntu Studio | OS Version | 15.10 | ||
| Product Version | 1.4.6 | ||||
| Summary | 0014263: Replace character and paragraph "Styles" with CSS-like style directives | ||||
| Description | With styles, there doesn't appear to be any way to combine styles such that you can create meaningful, reusable styles that are easy to maintain. For example, imagine I want all hyperlinks to be blue. I create a "hyperlink" style and change the color to blue. But that style also captures the font face, font size, and a number of other characteristics. If I then create a feature box in which I want my font size to be smaller, for example, I have to either manually apply the new font size after applying the "Hyperlink" character style, or manually apply the characteristics of the hyperlink style after applying the "feature box" style to the text box. A solution to this would be to create a DSL based on CSS (which you could hide behind a GUI if desired, so it could work similarly to the current styles GUI). You could define various classes which you could combine on entire text boxes, paragraphs, or individual character selections. In the above example, my base class might be `.my-class { font: normal 12pt/14pt Times; }`, then I would create a "feature-box" style like this: `.feature-box { font-size: 11pt; line-height: 13pt; }`, and then `.hyperlink { font-color: blue; }`. In the properties panel, then, you could replace the single-selects for paragraph style and character style with multiselects, and these would be applicable to a) the entire text box, when the box is selected but is not in "editing" mode; b) the current paragraph, if no character selections are made; or c) the characters selected. | ||||
| Tags | No tags attached. | ||||
| Patch | No | ||||
|
|
very interesting suggestion. i have been working for years with css and i see what the advantages are! but it can also become a hell of important! cross directives. i think that we need a detailed proposal that tells which subset of the css way of working will be supported by scribus and defines a list of steps that we have to go through for implementing. |
|
|
a first suggestion: i would not enable multiple styles to be applied to a single selection. i would prefer to add the concept of style class that can be applied on top of / in parallel to the styles mechanism. in the document settings, one could choose if she wants to work with style classes (more flexible but also more complex) or with normal styles (probably the default way). if we discover that the classes mechanism is superior in every case, we can keep the style as they currently are, for defining the formatting attached to a name but rely only on classes for applying the formatting to the content. i would try to avoid mixing the rules for applying a formatting with the definition of the formatting itself (this is in my eyes one of the parts of css / html that makes the whole system fragile) |
|
|
Glad to see someone else sees value in this! Now, I'm totally new to contributing in this way. Is a formal proposal something I could write up myself and submit? Or could I at least start it and put it on Google Drive so we can open it up to comments and edits? Honestly, what I think would be much more far-reaching than focusing on how Scribus could implement limited CSS functionality is to assume that Web and Desktop Publishing are converging, and to instead *extend* HTML/CSS to include the features we need in Desktop Publishing. Then Scribus would only have to implement this extended HTML/CSS spec, and much of the continued back-end work would be done by open source HTML renderers like WebKit. In fact, the Scribus "engine" would most logically be implemented as a fork of WebKit that extends it to include the features we need. Think about it: Scribus already uses an XML format, which can just as easily be XHTML. And as for the state of the state in HTML/CSS, they already have column layouts, margins, paddings, detailed font specifications, images, a vague layering concept, opacity, etc.... I mean, there are some projects that have been done in Scribus that I could already convert into HTML and print to PDF right from my browser. It seems conceptually easy to add in things like SVG-based frame contours (for more complicated word wrap), hyphenation, and better layer support. Granted, there are a lot of non-negotiable features in Scribus that really give it its value, and I'm not saying that we just use web browsers and printing to PDF to publish docs. But I am saying we can relieve ourselves of an enormous engineering burden by using the work they're already doing as a starting point and adding in all the value-adding features that Scribus has now and on the development roadmap. I know this may seem like an unreasonable proposal right now, but if we spent the next year converting the program to an extended WebKit backend, we would benefit enormously far into the future from the active development of already-existing technologies. The 5-year plan already makes sense, and the 10-year plan is a total no-brainer. What do you think? P.s., I say "we", and by that I mean I wish I knew enough C++ to actually contribute, and I'd love to start writing little pieces under someone's guidance as a way to learn :). But "we" means you guys until a year or two from now when I'm actually useful and relatively independent in C++! |
|
|
there are two different problems: - using css-like formatting instructions in the .sla files. this is something that is planned for the future - using a css-like way to apply the formatting (`.chapter .title {...}`). this something i thought you were talking about... but you were not (but it's still very interesting :-) concerning a way to contribute to a switch to css formatting, one thing you can contribute is by producing a list of all formatting scribus uses (eventually with the name currently used in the .sla files) and finding an existing css/svg property name that we can use. for the properties that do not exist in css (they might be some) sugges a new name (probably prefixed with sla- or scribus-). you don't need any programming skills for this... and if you wonder what can do a designer that has spent a few months learning enough c++ for contributing to scribus, you can have a look at indigodock: https://github.com/nitramr/indigoDock martin is a designer who decided that he wanted to program a "fake" application that shows how a new palette can work in scribus... if you want to learn to program, it's not me who will hinder you :-) but you can help even without programming skills! |
|
|
ah, and there is of course a third problem: - defining the styles in a css-like way... the more i think about it, the more i like it :-) |
|
|
Personally, I think we'd do well to zoom out and see the three problems you've mentioned as different facets of the same overall issue: We need more granular and easier-to-use style facilities in Desktop Publishing, and that problem has been elegantly and effectively solved in the very-related world of Web by CSS. To me, it seems like investing a great deal of thought in exactly how we might approximate CSS in Scribus is unnecessary. Were we to do that, we would likely end up with a unique specification that's 90% the same as CSS, but enormous work to maintain and update. I feel like it would be more productive to instead recognize that the same fundamental problem (highly granular and reusable styling) has been solved in a way that has proven its merits through over a decade of active use, and simply extend that solution and specification to address the parts of our problem that it doesn't yet address (but someday probably will). Anyway, I'm going to try to dig into this more over the coming weeks and see if I can work up some examples of how this might all go together and how it might affect the document creation workflow. I'll see if I can work up some interface mockups, too. And hey, thanks again for being so open to suggestions! I look forward to getting more into this. |
|
|
yes, we have to find which css properties apply to scribus and list them. that's what i wanted to say. not invent a new css-like set of properties. a few won't exist yet (or will only be in some proposals). that 10% (or less) will have to be created. imo, having a list of all those properties, if possible with the matching name currently used in the .sla files, could be very helpful for the ones who will change the .sla file format to support a css-like syntax. |
|
|
Alright, then that's my job! ;) I've got a crunch coming in the next few weeks, but hopefully I'll be able to get this going sometime in the not-too-distant future. For now, here's an open Google Drive folder where I'll be developing concepts and will eventually start developing the list: https://drive.google.com/open?id=0ByWtXkhNf140aS1jYUd0REU5RjA As I said, I won't be able to get going on this for a little while, but feel free to check in there or bump this thread as time goes on. I'll do the same. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-08-14 04:40 | kael | New Issue | |
| 2016-08-15 08:09 | ale | Note Added: 0041907 | |
| 2016-08-15 08:19 | ale | Note Added: 0041908 | |
| 2016-08-15 08:48 | ale | Note Edited: 0041908 | |
| 2016-08-15 08:49 | ale | Note Edited: 0041908 | |
| 2016-08-17 04:34 | kael | Note Added: 0041914 | |
| 2016-08-17 20:33 | ale | Note Added: 0041916 | |
| 2016-08-18 07:09 | ale | Note Added: 0041917 | |
| 2016-08-18 14:48 | kael | Note Added: 0041918 | |
| 2016-08-18 20:31 | ale | Note Added: 0041919 | |
| 2016-08-18 21:19 | kael | Note Added: 0041920 |
