News:
Problems registering, no confirmation email - see http://wiki.scribus.net/canvas/Forums_Registration
Recent posts
#91
Scripts and Plugins / Re: Custom keyboard shortcut f...
Last post by a.l.e - November 20, 2024, 09:07:40 PMThe patch is in 1.7svn.
Yeah!
Now you can
If you can get a build, please try it out and see if it fits your needs.
Yeah!
Now you can
- Add a directory with your scripts in the scripter's preferences.
- Use ctrl-/ to open the action search and type a few letters from the script name to start it.
If you can get a build, please try it out and see if it fits your needs.
#92
Code / Re: Proposal for new SLA file ...
Last post by tim_occ - November 20, 2024, 04:27:56 PMIt looks like InDesign Page Layout Template Files (indt) take a similar approach. It is a binary file format, but most likely an archive file, as I have found references to embedded XML and xpacket files.
#93
Code / Re: Proposal for new SLA file ...
Last post by tim_occ - November 20, 2024, 04:09:22 PMHi ale,
very good input.
You're right, I think that before we consider just "minor" changes, a new file format should first and foremost be somewhat future-proof.
The idea of collaborative work is fascinating. From my experience, the biggest problem is when 2 users edit the same file. We have the same problem in the development of Scribus and merge conflicts can occur.
I think that in order for collaborative work to be possible at all, we need to split the current file into many small files that can then be changed independently of each other.
As an example, a Sketch app file is structured similarly to what you suggested. It is a zip file with separate files. See here: https://developer.sketch.com/file-format/
We could take a similar approach. As a principle for a new file format, the structure should be split into blocks that are exclusively referenced.
These blocks could then either be stored in folders (wherever they are located) or as a "compact version", these blocks are stored in the SLA file, as is the case now.
Here is an illustration of how I imagine the structure.
The index contains a list of the locations of the various assets. If an item is missing, Scribus would assume the information is within the file itself. For stored assets, relative or absolute paths would then be specified here. Storing files also allows you to work with a version control such as git or diff.
very good input.
You're right, I think that before we consider just "minor" changes, a new file format should first and foremost be somewhat future-proof.
The idea of collaborative work is fascinating. From my experience, the biggest problem is when 2 users edit the same file. We have the same problem in the development of Scribus and merge conflicts can occur.
I think that in order for collaborative work to be possible at all, we need to split the current file into many small files that can then be changed independently of each other.
As an example, a Sketch app file is structured similarly to what you suggested. It is a zip file with separate files. See here: https://developer.sketch.com/file-format/
We could take a similar approach. As a principle for a new file format, the structure should be split into blocks that are exclusively referenced.
These blocks could then either be stored in folders (wherever they are located) or as a "compact version", these blocks are stored in the SLA file, as is the case now.
Here is an illustration of how I imagine the structure.
Code Select
<?xml version="1.0" encoding="utf-8"?>
<scribusUTF8New Version="2.0">
<index>
<item type="colors" location="" />
<item type="gradients" location="" />
<item type="patterns" location="" />
<item type="opticalMarginSets" location="" />
<item type="hyphens" location="" />
<item type="characterStyle" location="" />
<item type="paragraphStyle" location="" />
<item type="lineStyle" location="" />
<item type="noteStyle" location="" />
<item type="toc" location="" />
<item type="indexes" location="" />
<item type="sections" location="" />
<item type="layers" location="" />
<item type="masterPages" location="" />
<item type="pages" location="" />
<item type="docItemAttributes" location="" />
<item type="pdf" location="" />
<item type="printers" location="" />
<item type="images" location="" />
<item type="text" location="" />
</index>
<document>
...
</document>
</scribusUTF8New>
The index contains a list of the locations of the various assets. If an item is missing, Scribus would assume the information is within the file itself. For stored assets, relative or absolute paths would then be specified here. Storing files also allows you to work with a version control such as git or diff.
#94
Beginner Talk / Re: Making a bilingual book
Last post by Gy1l0om - November 20, 2024, 02:11:14 PMThat was indeed me on reddit, so thank you one more time (also, hello fellow Swiss person) 
My post on reddit clearly wasn't accurate enough, but what you're describing now seems perfect for my needs ! Many thanks, I'll get to work now.
My post on reddit clearly wasn't accurate enough, but what you're describing now seems perfect for my needs ! Many thanks, I'll get to work now.
#95
Code / Re: Proposal for new SLA file ...
Last post by a.l.e - November 19, 2024, 08:46:18 PMbasically: a very good idea.
some input from my side:
we don't have to implement more feature that there are now in scribus. but if we do a change, i would love if we could make sure that the new .sla definition could make some future progress easier (or at least not being in the way).
if possible
some input from my side:
- if we create a new file format, i would love to have it specified in a DTD (there are enough people who want to do "crazy" things with scribus files and are already parsing and modifying them).
- would it be possible to have default values for some (many) attributes? when i have a look at a .sla file, i see lot (but lot!) of values that have not been been set specifically for that document....
- the elements should have a bit less arguments (your idea of embedding tags into others seems good to me)
- in a second step, we might want to allow some of the content to be external (text, styles, colors, ...).
- the external files might be packaged inside of a zip or really be located on a different part of the disk (or the net)
- and if we're already at that, we might want to think that in the future it should be possible to allow several people to work at the same time on a specific file (locking of resources)
- ... and allow the file to be accessed on a server from different computers (even not at the same time).
we don't have to implement more feature that there are now in scribus. but if we do a change, i would love if we could make sure that the new .sla definition could make some future progress easier (or at least not being in the way).
if possible
#96
Raster and Vector Graphics / Positionning a in text graphic...
Last post by Jean-Paul - November 19, 2024, 08:37:35 PMHello,
My English is very bad, so I'm not sure I respect all the rules of the forum and hope you will forgive me.
My problem is the following:
I place a graphic (containing a mathematical formula), by copying it from a GraphicBox, in a line of text of a TextBox. When the graphic is higher than a line of text, I position the graphic vertically using one of the variables of the advanced parameters of the text properties. The graphic is then positioned at the height I want, but the whole line does not move vertically taking into account the offset introduced.
How to solve this problem?
I use Scribus 1.6.2 under Windows 10
Regards
My English is very bad, so I'm not sure I respect all the rules of the forum and hope you will forgive me.
My problem is the following:
I place a graphic (containing a mathematical formula), by copying it from a GraphicBox, in a line of text of a TextBox. When the graphic is higher than a line of text, I position the graphic vertically using one of the variables of the advanced parameters of the text properties. The graphic is then positioned at the height I want, but the whole line does not move vertically taking into account the offset introduced.
How to solve this problem?
I use Scribus 1.6.2 under Windows 10
Regards
#97
Beginner Talk / Re: Making a bilingual book
Last post by a.l.e - November 19, 2024, 08:12:50 PMI've read your question already on Reddit (is it indeed you?) and thought: no, Scribus is not really the right choice for a bilingual book.
The issue is that you cannot synchronize the start of the paragraphs and keep the flow going hand in hand on both sides.
But.
But, now that I read a bit better your question, you're asking something different.
Yes, it is possible to import (or paste) a text that flows on the left pages and one other that flows on the rights ones.
And it's even pretty easy to do so.
Now, you have your text and you can add spaces or even try to split the frame inside of a page to manually synchronize the start of the paragraphs / sections / chapters (whatever you want to synchronize...)
The issue is that you cannot synchronize the start of the paragraphs and keep the flow going hand in hand on both sides.
But.
But, now that I read a bit better your question, you're asking something different.
Yes, it is possible to import (or paste) a text that flows on the left pages and one other that flows on the rights ones.
And it's even pretty easy to do so.
- Create a Scribus document with facing pages.
- Create the first pages, up to the first two where you want the translated text to start (I have created three of them: a cover page and two pages for the facing translations).
- Create a frame on each of the two pages where the translation starts.
- Paste (or load) your English text in the frame on the left page and your French text in the one on the right side.
- Create n double pages where you want your text to flow into (I've created five of them): If it's not the right number, you can later add more pages in the same way or delete the ones which are left empty.
- Click on the frame on the left side and start "Item > Duplicate/Transform > Multiple Duplicate".
- Activate the "By page" tab.
- Select "Following Even Pages" and check the box for "Link Text Frames"
- Do the same for the right page and the odd following ones.
Now, you have your text and you can add spaces or even try to split the frame inside of a page to manually synchronize the start of the paragraphs / sections / chapters (whatever you want to synchronize...)
#98
Beginner Talk / [SOLVED] Making a bilingual bo...
Last post by Gy1l0om - November 19, 2024, 04:21:21 PMHello there 
I've read a few tutorials on the basics but I've yet to find this information.
I'm making bilingual books, with English on left pages and French on right pages.
How can I automate the process of linking text boxes on left pages and text boxes on right pages ? I know how to make it by hand, but we're talking hundreds, thousands of pages accross seven books. I'm sure there's a better way. Is there a script/plugin that does that or a native way I've not yet come accross ?
Thanks a lot in advance !
I've read a few tutorials on the basics but I've yet to find this information. I'm making bilingual books, with English on left pages and French on right pages.
How can I automate the process of linking text boxes on left pages and text boxes on right pages ? I know how to make it by hand, but we're talking hundreds, thousands of pages accross seven books. I'm sure there's a better way. Is there a script/plugin that does that or a native way I've not yet come accross ?
Thanks a lot in advance
! #99
Code / Proposal for new SLA file stru...
Last post by tim_occ - November 19, 2024, 01:29:29 PMHello everyone,
I know that this is a sensitive topic. Nevertheless, I believe that the SLA file needs some improvements. Among other things, it still contains German attribute names for historical reasons. I also noticed that the file structure is "too flat". When the file is read in, all lines are read individually and checked for corresponding tags. This means that an unnecessary number of comparisons have to be carried out, which is particularly slow for large files. In addition, the efficiency advantages of the XML format are not used, namely that information can be read quickly via blocks and processed further in a targeted manner. In newer implementations, these blocks already exist, which is good.
I therefore suggest that most of the old tags be grouped into new parent tags.
An example using color tags. The same applies to styles and many other tags.
Previously:
Suggestion:
Grouping tags has the advantage that you don't have to go through the entire document line by line to extract all the colors. This is a big advantage when importing data from one document into another document.
As far as I can tell, the new file loader only needs to be able to read the new format, as the old formats will continue to work via the old file loader plugins. In addition, Craig has already built in a function that allows users to save a new document in an older format. So at this point, I don't see any major problems changing the file format for newer versions of Scribus.
See attached file for a proposal structure. It is not intended to be complete.
PS: It is a good chance to replace the German names too and unify the code style, like "COLOR", "MultiLine" or "useColor".
I know that this is a sensitive topic. Nevertheless, I believe that the SLA file needs some improvements. Among other things, it still contains German attribute names for historical reasons. I also noticed that the file structure is "too flat". When the file is read in, all lines are read individually and checked for corresponding tags. This means that an unnecessary number of comparisons have to be carried out, which is particularly slow for large files. In addition, the efficiency advantages of the XML format are not used, namely that information can be read quickly via blocks and processed further in a targeted manner. In newer implementations, these blocks already exist, which is good.
I therefore suggest that most of the old tags be grouped into new parent tags.
An example using color tags. The same applies to styles and many other tags.
Previously:
Code Select
<COLOR NAME="Black" SPACE="CMYK" C="0" M="0" Y="0" K="100"/>
Suggestion:
Code Select
<Colors>
<COLOR NAME="Black" SPACE="CMYK" C="0" M="0" Y="0" K="100"/>
</Colors>
Grouping tags has the advantage that you don't have to go through the entire document line by line to extract all the colors. This is a big advantage when importing data from one document into another document.
As far as I can tell, the new file loader only needs to be able to read the new format, as the old formats will continue to work via the old file loader plugins. In addition, Craig has already built in a function that allows users to save a new document in an older format. So at this point, I don't see any major problems changing the file format for newer versions of Scribus.
See attached file for a proposal structure. It is not intended to be complete.
PS: It is a good chance to replace the German names too and unify the code style, like "COLOR", "MultiLine" or "useColor".
#100
PDF Generation / Re: Nothing happens when hitti...
Last post by Casiosudd - November 19, 2024, 12:37:09 PMI tried to reinstall both Scribus (same old version 1.3.3.14) and Ghostscript (new). Did not solve the problem.
But after installing a new Scribus version (1.6.2) the pdf-export works again.
Instead inserted pdf's have moved slightly when opened in 1.6.2 - annoying, but at least I know how to fix it.
But after installing a new Scribus version (1.6.2) the pdf-export works again.
Instead inserted pdf's have moved slightly when opened in 1.6.2 - annoying, but at least I know how to fix it.