News:
Problems registering, no confirmation email - see http://wiki.scribus.net/canvas/Forums_Registration
Recent posts
#41
Code / Feature discussion: content va...
Last post by BN_Dev - September 23, 2024, 03:03:26 AMHi all,
An essential feature we need is something analogous to Content Variables in QuarkXPress. See QuarkXPress 2024 User Guide: Content Variables.
I am aware that the Marks feature exists and is experimental. It is very promising and we are excited that it could offer better functionality than Content Variables. We have been playing with this feature and found a few bugs (which I have started reporting via Mantis; see 0017269: Ascent not computed with variable text).
We would like to contribute work in this area for the following goals:
Referencing the post at the top, whilst we recognize that a lot of this is possible by directly manipulating the XML file with external tools and with the use of plugins (I have seen an example of a mail-merge type system that does this), having something built-in that's analogous to Content Variables makes time-saving smarter layout features available to everyone without having rely on anything external and is document-portable.
A few example of our actual use case in a newsprint production include:
Many thanks,
Paul
Quote from: BN_Dev on September 23, 2024, 02:07:24 AM^^ With regards to this post ^^
An essential feature we need is something analogous to Content Variables in QuarkXPress. See QuarkXPress 2024 User Guide: Content Variables.
I am aware that the Marks feature exists and is experimental. It is very promising and we are excited that it could offer better functionality than Content Variables. We have been playing with this feature and found a few bugs (which I have started reporting via Mantis; see 0017269: Ascent not computed with variable text).
We would like to contribute work in this area for the following goals:
- To ensure that variable text is treated identically to text entered in to a text frame and has all the correct formatting and behavior of non-variable text
- A view toggle option to highlight Mark objects with a different background color
- To support a type of dynamic variable text whose contents can be updated based on a template or light code solution, such as:
- Set by the contents of an external file path
- Set by a simple Excel-like macro; =DATE('MMM YYYY')
- Access properties of the document or program, such as last save datetime/current file path/etc.
- Extracting "running headers" or other conditional input from the page/section/document, such as current chapter or section name
- An idea to set the content as the output of a Python script that is automatically invoked when fields are updated
- To allow certain variable text Marks to reference others and be embedded/nested
- With an updated UI editor to allow easy access to choosing functionality for the content the user desires
- A new Mark type to allow dynamic picture frame URI
- Using a Mark text to allow dynamic generation/updating of a barcode based on it
- Relevant/associated API interfaces for Scripts to also access/modify these things in a document
Referencing the post at the top, whilst we recognize that a lot of this is possible by directly manipulating the XML file with external tools and with the use of plugins (I have seen an example of a mail-merge type system that does this), having something built-in that's analogous to Content Variables makes time-saving smarter layout features available to everyone without having rely on anything external and is document-portable.
A few example of our actual use case in a newsprint production include:
- Having the issue date as a content variable in the master template that is updated once but referenced in the headers and masthead so no issue ever has the previous incorrect date
- Generating the EAN 13+2 sales barcode for each edition+issue (ISSN+week number)
- Running header for current section name (also potential to use for ToC index)
Many thanks,
Paul
#42
Code / Re: Best forum
Last post by BN_Dev - September 23, 2024, 02:07:24 AMThanks @all, it's been nice to start getting involved and the community is very friendly. I used to use svn before git; I was worried I forgot everything but it all came back to me quickly and I'm happy to use it until/if the project officially switches. I found the process to start submitting patches was easy, plus KDevelop has made it super fast to jump straight in although I mostly live in the terminal.
I finally have a list but it took a small while longer than I thought to collate feedback related to my post above:
I'm going to start typing them out now and I'll put an index post after this one with links directly to them. Our ultimate hope is to switch from QuarkXPress to Scribus for an existing production workflow without any downtime. In order for us to do this we have classified features as essential/desired/future. For essential features we intend to be present and actively work on these and contribute to them in a way that supports our goals whilst also being useful for other users and improving the software overall. If we can meet all our essential needs we will certainly switch to Scribus.
Functionality considered desired are things we can work towards without time constraints and it doesn't matter if they aren't all possible as any pain points are likely to be less than what we currently have with QXP. Functionality considered future is long-term roadmap stuff and we will be happy to continue to commit resources to ensuring Scribus stays on-par with QXP/ID and their offerings.
Our hope is that by working with an open-source project to recreate the features we need in production we can offer a migration path for other publications off proprietary layout software too. As a background project we have also considered documenting how we intend to achieve the QXP>Scribus migration plus the actual migration itself (if it becomes possible) to offer a blueprint for others.
At the very core of a lot of consideration for Scribus is the open XML file format; which is far more accessible than Quark's .QXP format. Some of the features we need could be implemented with external tooling to modify tags if all else fails; but we feel this is too hacky and we would rather have actual native UI support that all users can benefit from on all platforms without external tooling.
Many thanks,
Paul
I finally have a list but it took a small while longer than I thought to collate feedback related to my post above:
Quote from: BN_Dev on September 08, 2024, 07:28:12 AMOver the course of the next week I'll open separate threads for each feature to keep the discussion focused to that particular feature.
I'm going to start typing them out now and I'll put an index post after this one with links directly to them. Our ultimate hope is to switch from QuarkXPress to Scribus for an existing production workflow without any downtime. In order for us to do this we have classified features as essential/desired/future. For essential features we intend to be present and actively work on these and contribute to them in a way that supports our goals whilst also being useful for other users and improving the software overall. If we can meet all our essential needs we will certainly switch to Scribus.
Functionality considered desired are things we can work towards without time constraints and it doesn't matter if they aren't all possible as any pain points are likely to be less than what we currently have with QXP. Functionality considered future is long-term roadmap stuff and we will be happy to continue to commit resources to ensuring Scribus stays on-par with QXP/ID and their offerings.
Our hope is that by working with an open-source project to recreate the features we need in production we can offer a migration path for other publications off proprietary layout software too. As a background project we have also considered documenting how we intend to achieve the QXP>Scribus migration plus the actual migration itself (if it becomes possible) to offer a blueprint for others.
At the very core of a lot of consideration for Scribus is the open XML file format; which is far more accessible than Quark's .QXP format. Some of the features we need could be implemented with external tooling to modify tags if all else fails; but we feel this is too hacky and we would rather have actual native UI support that all users can benefit from on all platforms without external tooling.
Many thanks,
Paul
#43
Layout Issues / Re: Table of contents changes ...
Last post by utnik - September 21, 2024, 11:55:09 PMhi flaxx
it should be the level of the frames. (it's the order in which you've created the frames in the first place. but you may change it in 'preferences' → 'x,y,z' → 'level'...)
utnik
Quote from: Flaxx on September 21, 2024, 09:56:11 PM...it often happens that the top-down order of those articles appears random...
...What is the parameter, that Scribus is looking for? It doesn't seems to be the internal frame number nor an alphabetical order.
it should be the level of the frames. (it's the order in which you've created the frames in the first place. but you may change it in 'preferences' → 'x,y,z' → 'level'...)
utnik
#44
Layout Issues / Table of contents changes the ...
Last post by Flaxx - September 21, 2024, 09:56:11 PMHi, probably I'm wrong here, but my question might have to do with layout as well - somehow. 
If not, please move it to the right place.
First: Scribus 1.6.2 is installed on Windows 11 Pro, as well on Linux Mint 22 Cinnamon (dual boot), and portable on USB.
I'm quite comfortable with the usual way how to create tables of contents. I'm doing the layout of a club-internal monthly newspaper (usually 20 to 28 pages), where one chapter allows member groups announcing their meetings and the planned topics on a couple of pages. As these are mostly short paragraphs it usually happens, that more than one (up to four) are published on a single page - all in the same way. The order likely changes from month to month.
The leftmost frame, with the title of each group, is usually marked by unchanged attributes as the one appearing in the TOC. The right one has the content.
After generating the TOC it often happens that the top-down order of those articles appears random. This means, that the third article on a page might stands on top, followed by the second one, and so far.
As I didn't find a way to force the correct sequence, I always have to change the order manually.
My question: What is the parameter, that Scribus is looking for? It doesn't seems to be the internal frame number nor an alphabetical order.
If not, please move it to the right place.
First: Scribus 1.6.2 is installed on Windows 11 Pro, as well on Linux Mint 22 Cinnamon (dual boot), and portable on USB.
I'm quite comfortable with the usual way how to create tables of contents. I'm doing the layout of a club-internal monthly newspaper (usually 20 to 28 pages), where one chapter allows member groups announcing their meetings and the planned topics on a couple of pages. As these are mostly short paragraphs it usually happens, that more than one (up to four) are published on a single page - all in the same way. The order likely changes from month to month.
The leftmost frame, with the title of each group, is usually marked by unchanged attributes as the one appearing in the TOC. The right one has the content.
After generating the TOC it often happens that the top-down order of those articles appears random. This means, that the third article on a page might stands on top, followed by the second one, and so far.
As I didn't find a way to force the correct sequence, I always have to change the order manually.
My question: What is the parameter, that Scribus is looking for? It doesn't seems to be the internal frame number nor an alphabetical order.
#45
PDF Generation / Re: [SOLVED] Incorrectly Scale...
Last post by AdmFubar - September 20, 2024, 10:59:28 PMThe best I could do is using PDF/X-4 for the exported PDF. but this still has a small off white border around the shadow when imported into scribus on linux.
#46
PDF Generation / Re: [SOLVED] Incorrectly Scale...
Last post by OSDP - September 20, 2024, 01:51:53 AMThe icc color profile of an image or document can be RGB or CMYK. You can also export an image or a .pdf without integrating an icc color profile (it does not prevent that it will have been created from an RGB or CMYK icc profile).
Some export of .pdf accept RGB and CMYK images mixed.
Others (dedicated to printing) convert all content into CMYK.
Some pdf exports do not accept transparencies, others do.
https://en.wikipedia.org/wiki/ICC_profile
https://en.wikipedia.org/wiki/PDF
https://pdfa.org/resource/pdf-specification-archive/
https://pdfa.org/pdf-standards/
https://helpx.adobe.com/acrobat/using/pdf-x-pdf-a-pdf.html
https://www.adobe.com/uk/acrobat/resources/document-files/pdf-types.html
Some export of .pdf accept RGB and CMYK images mixed.
Others (dedicated to printing) convert all content into CMYK.
Some pdf exports do not accept transparencies, others do.
https://en.wikipedia.org/wiki/ICC_profile
https://en.wikipedia.org/wiki/PDF
https://pdfa.org/resource/pdf-specification-archive/
https://pdfa.org/pdf-standards/
https://helpx.adobe.com/acrobat/using/pdf-x-pdf-a-pdf.html
https://www.adobe.com/uk/acrobat/resources/document-files/pdf-types.html
#47
User Interface / Re: Indigo UI: Text Properties
Last post by BN_Dev - September 20, 2024, 01:40:04 AMThey look clear and pretty. How's it like in dark mode? I have a little issue with the dark mode pop-outs in the widgets because they're borderless and easily blend in to things. More than once I've not even realized something popped out and wondered why other controls weren't responding 
#48
PDF Generation / Re: [SOLVED] Incorrectly Scale...
Last post by OSDP - September 20, 2024, 01:13:33 AMThe issues are the conversion (or not) of images to the desired icc profile (CMYK) in final .pdf and interpretations of shadows and transparencies according to third party reading software (may be temporary if only related to your version/configuration of linux), why not exporting your final work in a .pdf that would contain only a single raster image (CMYK) ? You will see on live the results of shading that you can adjust until satisfation by exporting and testing in .tiff or .jpg. You can export this CMYK image, and insert it in .pdf (which will have only a single raster image, no vector font, no shading software effect (from scribus or inkscape).
My procedure is fine for small formats and simple documents: A4, sometimes A3.
I rarely print (and only in four colors) (posters in general).
Beyond that, the .tiff or .jpg will likely be really heavy/too heavy (depending on the nature and complexity of the work).
And it is true that this requires additional steps (which I have not specified):
For example, if I have to take out a final .pdf in A4 300dpi, with a 5 mm requested bleed, I must think of composing and working my Scribus document in «custom format», so as to export my image .jpg or .tiff with adequate bleed integrated in output ! Very important here. For this example, 10 mm more in width and height. So, my work/document .sla (and my .jpg/tiff output image) "A4" will then have to be 220 x 307 mm (custom format, with a bleed zero for this step) instead of 210 x 297 mm (A4 format).
To «see» the bleed area, you can put a colored shape (A4 format) on a dedicated layer in the background.
And to finalize it in .pdf for printing, I reimport the 100% raster image from this first .sla in another .sla document (this time in A4 format via the Scribus interface, setting a 5 mm bleed), and by shifting the image to "x" and "y" (in this example: -5 mm and -5 mm).
This either wastes time, or actually saves time, depending on the outcome. The first time, it is quite laborious (especially since Scribus does not propose the «pixel» unit; and it will be necessary to convert millimeters into pixels as the reverse to find themselves in the «process»). The next time, it's better. In any case, the potential issues related to effects (shadows) and fonts "no longer exist" with the printer. (You will have to manage them yourself if there are any; until .jpg/tiff comes out as you want). For transparencies, the same will be checked "in output" if everything is "ok".
It may be quite laborious, but in the end, the final .pdf should not pose a problem: it is "like printing a photo".
In some circumstances, it may be useful !
My procedure is fine for small formats and simple documents: A4, sometimes A3.
I rarely print (and only in four colors) (posters in general).
Beyond that, the .tiff or .jpg will likely be really heavy/too heavy (depending on the nature and complexity of the work).
And it is true that this requires additional steps (which I have not specified):
For example, if I have to take out a final .pdf in A4 300dpi, with a 5 mm requested bleed, I must think of composing and working my Scribus document in «custom format», so as to export my image .jpg or .tiff with adequate bleed integrated in output ! Very important here. For this example, 10 mm more in width and height. So, my work/document .sla (and my .jpg/tiff output image) "A4" will then have to be 220 x 307 mm (custom format, with a bleed zero for this step) instead of 210 x 297 mm (A4 format).
To «see» the bleed area, you can put a colored shape (A4 format) on a dedicated layer in the background.
And to finalize it in .pdf for printing, I reimport the 100% raster image from this first .sla in another .sla document (this time in A4 format via the Scribus interface, setting a 5 mm bleed), and by shifting the image to "x" and "y" (in this example: -5 mm and -5 mm).
This either wastes time, or actually saves time, depending on the outcome. The first time, it is quite laborious (especially since Scribus does not propose the «pixel» unit; and it will be necessary to convert millimeters into pixels as the reverse to find themselves in the «process»). The next time, it's better. In any case, the potential issues related to effects (shadows) and fonts "no longer exist" with the printer. (You will have to manage them yourself if there are any; until .jpg/tiff comes out as you want). For transparencies, the same will be checked "in output" if everything is "ok".
It may be quite laborious, but in the end, the final .pdf should not pose a problem: it is "like printing a photo".
In some circumstances, it may be useful !
#49
Text and Typography / Re: Font letter is being trunc...
Last post by AdmFubar - September 19, 2024, 10:38:04 PMI'm not seeing the issue. It seems to work for me. Perhaps I am missing something?
#50
Text and Typography / Re: Font letter is being trunc...
Last post by Fog81 - September 19, 2024, 06:39:05 PMyes i confirm the pdf is not having problem but only when you vectorize the font.
I'm opening a ticket right away thanks
I'm opening a ticket right away thanks