News:
Problems registering, no confirmation email - see http://wiki.scribus.net/canvas/Forums_Registration
Recent posts
#61
Installation and Setup / Re: scribus on 4k display
Last post by ajwe - November 21, 2024, 03:32:09 PMI hope it's okay that I add on to this thread, as I'm having the same problem as the original poster. I recently dumped Windows and moved to Linux Mint 22 and am hoping to be able to use Scribus. However, on my 3840x2160 monitor, it's very difficult to use. I tried a previous suggestion (setting QT_SCALE_FACTOR) and that makes some things like fonts bigger, but it doesn't fix all of the problems. Attached is a screenshot where the icons at the top are painfully small and on some of the popup windows the choices in the left column aren't readable (and resizing the window doesn't seem to allow me to resize that left column).
I have made other preference changes to Linux Mint's Display to get most other applications to look right (Monitor Scale set to 150% and using large icons on GIMP, for instance) and it seems to be working very nicely overall.
Any suggestions for other things to try to make Scribus work? Thanks!
I have made other preference changes to Linux Mint's Display to get most other applications to look right (Monitor Scale set to 150% and using large icons on GIMP, for instance) and it seems to be working very nicely overall.
Any suggestions for other things to try to make Scribus work? Thanks!
#62
Scripts and Plugins / Re: Improve the Own Scripts me...
Last post by AdmFubar - November 21, 2024, 03:41:00 AMShouldn't the "refresh" be a menu entry in in the scripts menu?
and for the menu entry in the list of scripts, a title entry in the script itself to define its name?
and for the menu entry in the list of scripts, a title entry in the script itself to define its name?
#63
Code / Re: Proposal for new SLA file ...
Last post by AdmFubar - November 21, 2024, 03:32:17 AMQuote from: MrB on November 20, 2024, 10:35:14 PMThe file format needs to be comprehensive and contain everything to support transition between computers, operating systems and versions of Scribus. Therefore, I believe omitting default values is not possible as they may change between versions of the code.Was about to mention the version differences. glad it was noted.
#64
Code / Re: Proposal for new SLA file ...
Last post by MrB - November 20, 2024, 10:35:14 PMThere's lots to work through if we want a comprehensive new file format. Not opposed to it.
However, 1.7.0 needs releasing, and I don't think 1.7.x should include such a new format. I'd rather work to deprecate 1.6.x, and stabilise 1.7.x to 1.8.0 (or whatever we call it, in reference to Ale's comments on versioning elsewhere). This helps us drop Qt 5. 1.7.x can have 1-2 more versions to ensure all the UI changes so far are fine. I want to release 1.6.3 and 1.7.0 this year still.
The file format needs to be comprehensive and contain everything to support transition between computers, operating systems and versions of Scribus. Therefore, I believe omitting default values is not possible as they may change between versions of the code.
It can be developed in parallel while other work continues, as long as the active load/save plugin is not this one. Easy to achieve and part of why I broke the old loaders into separate plugins many years ago.
Collaborative working is of interest. This was a plan about 20 years ago too, but the then developer didn't continue with it. He had written a server stub for Scribus that would enable clients to track changes (although it never got to a working stage). Unfortunately, there are parts of Scribus that would work well with this, eg sharing styles between running clients, but there would be a ton of work to get some of the most basic functions with some collaborative function. I think there's better things to focus on, eg tables.
Anyway, happy to discuss and observe...
However, 1.7.0 needs releasing, and I don't think 1.7.x should include such a new format. I'd rather work to deprecate 1.6.x, and stabilise 1.7.x to 1.8.0 (or whatever we call it, in reference to Ale's comments on versioning elsewhere). This helps us drop Qt 5. 1.7.x can have 1-2 more versions to ensure all the UI changes so far are fine. I want to release 1.6.3 and 1.7.0 this year still.
The file format needs to be comprehensive and contain everything to support transition between computers, operating systems and versions of Scribus. Therefore, I believe omitting default values is not possible as they may change between versions of the code.
It can be developed in parallel while other work continues, as long as the active load/save plugin is not this one. Easy to achieve and part of why I broke the old loaders into separate plugins many years ago.
Collaborative working is of interest. This was a plan about 20 years ago too, but the then developer didn't continue with it. He had written a server stub for Scribus that would enable clients to track changes (although it never got to a working stage). Unfortunately, there are parts of Scribus that would work well with this, eg sharing styles between running clients, but there would be a ton of work to get some of the most basic functions with some collaborative function. I think there's better things to focus on, eg tables.
Anyway, happy to discuss and observe...
#65
Scripts and Plugins / Improve the Own Scripts menu e...
Last post by a.l.e - November 20, 2024, 09:14:27 PMIt took a long time, but now we have a way to add the user's scripts to the Scripter menu entries:
https://bugs.scribus.net/view.php?id=15579
Now that it's in, I plan to do some further work and improve it.
Some ideas are:
Adding a "refresh" button in the preferences to rebuild the list of scripts
Create some sort of manifest to define the menu structure and the names of the scripts
Allow the user to add scripts in a new first section of the Scripter menu entry (without the sub menu)
Any other inputs?
https://bugs.scribus.net/view.php?id=15579
Now that it's in, I plan to do some further work and improve it.
Some ideas are:
Adding a "refresh" button in the preferences to rebuild the list of scripts
Create some sort of manifest to define the menu structure and the names of the scripts
Allow the user to add scripts in a new first section of the Scripter menu entry (without the sub menu)
Any other inputs?
#66
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.
#67
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.
#68
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.
#69
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.
#70
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