Recent posts

#51

Features / Re: New images on Flatpak?

Last post by enzogian - September 01, 2024, 05:42:49 PM

Hello there, sorry about not been clear on where should or could post a sort of request or help, to see if someone with expertise can help to create the flatpak installer for Scribus 1.6.2 in the Flathug dot org. https://flathub.org/  since every time I enter to find out there is still only the 1.6.1.
I am using MX Linux and I do install all via these portal called flatpak so I dont have a clue where else could I find a flatpak installer for MX Linux.
https://flathub.org/apps/net.scribus.Scribus
Hope it makes sense.
thanks a lot and regards

#52

User Interface / Re: Do you need inch input lik...

Last post by tim_occ - September 01, 2024, 02:46:58 PM

Ok, that is smart.

Looks like there is no need to change the input implementation. Thanks.

#53

PDF Generation / Re: [SOLVED] Incorrectly Scale...

Last post by zeronop - September 01, 2024, 01:41:16 AM

I i remeber correctly, scribus uses rgb internally. I do belive that there are plans to use cmyk down the road. Hopefully someone with that knowlege will chime in.
[/quote]

Scribus supports both RGB and CMYK as far as I know. I bring in CMYK encoded images all the time, and the color management tools will even show you if your CMYK images aren't within the gamut of the selected CMYK ICC color profile. Also, Scribus can export PDFs that can have CMYK encoded images.  Other layout programs, like Adobe InDesign, do the same thing.  So, if a program like InDesign is a good example of support of CMYK, then Scribus would fall into this same category for importing individual images and exporting PDFs

Where it seems to me to be lacking is importing an entire PDF that has CMYK encouded elements in it.  It just seems that when a PDF is imported it forces any images in the PDF to a RGB color space... For some reason.  I can't find a clear explanation as to why this is unfortunately, but I'm also unfamiliar with how other programs handle this, so maybe this is normal behavior for a page layout program.  Perhaps it's something that designers don't need to do very often.  I've only noticed that Scribus does this because I was see weird behavior with transparencies, and was having trouble finding a program that could help check if something was wrong with a PDF that someone had been toying with previously.

A free and long way around what I think is lackluster import behavior is to extract all the elements of the PDF using a tool like pdfimages in Linux (to preserve the native color spaces of the images in the PDF), and then rebuild the PDF from the ground up in Scribus by importing all the elements in one by one and imitating the layout of the original PDF.  This process isn't ideal, and allot of it could be avoid if during the PDF import process the user could select the color space and ICC profile to interpret images with.

#54

PDF Generation / Re: Incorrectly Scaled Drop Sh...

Last post by AdmFubar - August 31, 2024, 08:02:48 PM

When exporting the pdf, are you selecting the colorspace model? there is an option for screen/web, printer. or greyscale.

During this troubleshooting process I also learned that Scribus doesn't preserve the color space and profile when importing the PDF back into Scribus.  It seems to be brute forcing a CMYK to RGB color space conversion according to whatever default RGB color profile that is selected in preferences. I can see that this is the case when I check the image properties of any of the images from the imported PDF.  It is using and RGB color profile instead of the intended CMYK one that was being used before export and can be verified inside of the PDF using pdfimages.  I assume the transparencies for drop shadows are falling victim to this conversion process as well, but I can't find a way to extract and image from a pattern in Scribus, so I can't verify this specifically for the drop shadows. 

I i remeber correctly, scribus uses rgb internally. I do belive that there are plans to use cmyk down the road. Hopefully someone with that knowlege will chime in.

#55

PDF Generation / Re: Incorrectly Scaled Drop Sh...

Last post by zeronop - August 31, 2024, 07:42:46 AM

When exporting the pdf, are you selecting the colorspace model? there is an option for screen/web, printer. or greyscale.

Yes, I select "Printer" and tell it to "Use Color Profile" before I export, and I can confirm that the profile and color space are being properly preserved in my PDF using pdfimages.  I can also confirm that the printing company is doing another conversion of the all the images in the PDF because the images changed form "icc" to "CMYK" when comparing the original PDF and the soft proof PDF.  I imagine whatever conversion Illustrator is doing to the images in  the PDF is what is causing the rendering issues on my end.

During this troubleshooting process I also learned that Scribus doesn't preserve the color space and profile when importing the PDF back into Scribus.  It seems to be brute forcing a CMYK to RGB color space conversion according to whatever default RGB color profile that is selected in preferences. I can see that this is the case when I check the image properties of any of the images from the imported PDF.  It is using and RGB color profile instead of the intended CMYK one that was being used before export and can be verified inside of the PDF using pdfimages.  I assume the transparencies for drop shadows are falling victim to this conversion process as well, but I can't find a way to extract and image from a pattern in Scribus, so I can't verify this specifically for the drop shadows. 

It's a shame I can't tell the Scribus PDF importer to use native color space of the PDF and the embedded profile, or pick one from a drop down menu of install color profiles.  I don't how realistic it would be to add an option to select the desired color space and profile during the PDF import process, but it would be useful if possible.  I have done command line conversions using ghostscript in the past, and this more manual method allows you to define and input color profile and an output color profile when extractions or conversions of PDFs, so I imagine that this would be technically possible to implement in a front end GUI like Scribus.

Now knowing this, I believe that the PDF being imported and exported through various applications, and PDF viewers interpreting and displaying color spaces and profiles differently from application to application, are some of the reasons why this transparency issue with the drop shadows crops up from time to time.  I'm just going to have to deal with it by checking these softproofs in several different applications to see if they are consistent or not.  If there is a lack of consistency, I just have to choose to trust one and go with (most likely Adobe Acrobat because this is what the printer company is most likely using to check their softproof).  It sucks that inconsistency in PDF rendering in the Linux world keeps me tethered to windows.  It seems like a small silly thing to me, but I understand that color spaces and interpreting color is a complicated thing to deal with, and there aren't any perfect solutions, and plenty of opinions about how it ultimately should be dealt with.

Outside of just not using the drop shadow feature in Scribus, there doesn't seem to be a clear process to mitigate this transparency issue, and this is fine.  I can create drop shadows manually to ensure there aren't any issues with the soft proof (I actually did manually create drop shadows after seeing this transparency issue with the Scribus drop shadows, and didn't see the same problem in the second soft proof from the printing company after replacing the Scribus drop shadows with manually created ones).  I just wanted to make sure there wasn't some bug with Scribus, or some other Linux library, that might need to be addressed.  It's just a difference in how the color of a PDF from application to application.  Ultimately, what actually comes out of the printer ends up being the only thing that a designer can rely to gauge accuracy.

I'm going to mark this as solved at this point.  Thank you for you help and replies!

#56

Tutorials, Tips and How-Tos / Here's a SOLUTION to add/remov...

Last post by Greg P123 - August 31, 2024, 03:19:24 AM

Hi -

I got REALLY tired of the multiple mouse clicks to set/remove italics/bold, so I finally wrote a script to do it using keyboard shortcuts.

The script below will allow you to move up/down the font styles of your current font (cycling through Regular, Italics, Bold, etc).  Highlight your text and hit the shortcut -- that's it!

The script will work with Scribus in fullscreen mode or windowed - and on multi-monitor setups.

The script captures two keystrokes to go up/down the font styles (I used F5 and F6).  If you want to use other keystrokes, it's VERY easy to change (I describe how below).  The script will only capture the F5/F6 if Scribus is the active window, otherwise it passes the F5 and F6 through unchanged.

The whole 'intervention' requires just two files, and I'll share them here.  I'm running on Linux Mint, but this approach could be adapted for other OS's.  (If you do that, add your solution here!)

The two files are both located in the 'Home' folder (easy to find and work with).  They are '.xbindkeys' (to capture the keystrokes and call the script), and 'scribus_font_change.sh' (the script that does the work).  There is only one script because it gets called with a '1' or '2' parameter, depending on whether you want to go up or down the font styles.

Description of Method:

When I am editing text, I always have my Text Properties open on the right (and full height).  This means that the little arrow that activates the dropdown is always in the SAME POSITION relative to the top left right corner of the Scribus window.  This allows me to tell the script to 'click the mouse' on that dropdown arrow, go up/down using an arrow key, then hit 'Enter'.  Voila!

For my setup, the little dropdown arrow is 12 pixels to the left and 120 pixels below the top-right corner of the Scribus screen.  IF YOUR SETUP IS SLIGHTLY DIFFERENT, it's easy to adjust - just change the text of the script in one place.

First, capture the keystrokes:
Go to your Home folder, edit '.xbindkeys' and add these lines:

-----------------

"bash ~/scribus_font_change.sh 1"
   F5

"bash ~/scribus_font_change.sh 2"
   F6

-----------------

Next, create a file called 'scribus_font_change.sh' in the Home folder, add the lines below, and make the file executable.

-----------------

#!/bin/bash

# Check if a parameter is provided
if [ -z "$1" ]; then
  echo "Usage: $0 <parameter>"
  exit 1
fi

# Function to get the window ID under the mouse cursor
get_window_under_mouse() {
    xdotool getmouselocation --shell | grep WINDOW | sed 's/WINDOW=//'
}

# Function to click at a position relative to the window
click_at_position() {
    local window_id=$1
   
    # Get detailed window information
    win_info=$(xwininfo -id $window_id)
   
    # Extract window position and size
    X=$(echo "$win_info" | grep 'Absolute upper-left X' | awk '{print $NF}')
    Y=$(echo "$win_info" | grep 'Absolute upper-left Y' | awk '{print $NF}')
    WIDTH=$(echo "$win_info" | grep 'Width' | awk '{print $NF}')
   
    # Calculate click position relative to top-right corner
    click_x=$((X + WIDTH - 12))
    click_y=$((Y + 120))
   
    # Store current mouse position
    current_mouse=$(xdotool getmouselocation --shell)
    eval "$current_mouse"
   
    # Move mouse to calculated position and click
    xdotool mousemove $click_x $click_y click 1
   
    # Restore mouse position
    xdotool mousemove $X $Y
}

# Get the window ID under the mouse
WINDOW_ID=$(get_window_under_mouse)

# Check if Scribus is active or under the cursor
ACTIVE_WINDOW=$(xdotool getactivewindow getwindowname)
WINDOW_NAME=$(xdotool getwindowname $WINDOW_ID)

if [[ "$ACTIVE_WINDOW" == *"Scribus"* || "$WINDOW_NAME" == *"Scribus"* ]]; then
    # Perform actions based on the parameter
    case $1 in
        1)
            click_at_position $WINDOW_ID
            sleep 0.1
            xdotool key Up key Return
            ;;
        2)
            click_at_position $WINDOW_ID
            sleep 0.1
            xdotool key Down key Return
            ;;
        *)
            echo "Invalid parameter. Use 1 or 2."
            exit 1
            ;;
    esac
else
    # If not in Scribus, pass F5 for parameter 1 or F6 for parameter 2
    if [ "$1" -eq 1 ]; then
        xdotool key F5
    elif [ "$1" -eq 2 ]; then
        xdotool key F6
    fi
fi

-----------------

If you want to use keys other than F5/F6, then change the text that you add to '.xbindkeys' and the F5/F6 that appears at the very end of the script.

(You'll need to reset xbindkeys after any change to make the key capture active.)

If your screen setup is slightly different than mine, you may need to figure out where to 'mouse click' relative to the top-right corner (below the maximize button) - and change the offsets in the script (read the comments - it's easy to figure out).

Big thanks to Grok for it's help! 

I hope you enjoy.  It works GREAT over here.

- Greg

#57

PDF Generation / Re: Incorrectly Scaled Drop Sh...

Last post by AdmFubar - August 31, 2024, 02:38:21 AM

When exporting the pdf, are you selecting the colorspace model? there is an option for screen/web, printer. or greyscale.

#58

PDF Generation / Re: Incorrectly Scaled Drop Sh...

Last post by zeronop - August 30, 2024, 10:44:45 PM

Per chance do you have color management turned on?

Turning off color management makes the example PDF file appear as it should after importing it (it was exported in a US Web Coated SWOP color space), but the softproof from the printer is still having the transparency issues in Scribus (Linux and Windows) after importing and after turning off color management. Adobe Acrobat reader and muPDF seem to be the only two applications that can render these shadows in the softproof PDF correctly.


Perhaps this an issue cropping up as the colorspace of the images is ignored or changed when it's being imported between back into Scribus, and there is probably a color space change happening with the printer company imports and exports out of Illustrator.

I understand that some PDF viewers handle different color spaces better than others, that explains why Okular, Chrome, and Firefox are having issues.

I did some snooping with the linux commandline tool pdfimages.  My original PDF that I sent to the printer shows that the images have an icc profile attached to them.  This is intentional, as I work with TIF formated CMYK images with a US Web Coated SWOP color profile attached to them.  On the other hand, the softproof PDF from the printer company, running through pdfimages, shows that these images are listed as just cmyk (as opposed to icc).  I imagine that this is causing issues at some level. 

Scribus imports the drop shadows and patterns.  I wish I could extract the images from these patterns in Scribus in order to examine how Scribus is interpreting the color of these drop shadows after it imports them from the PDF.

#59

User Interface / Re: Do you need inch input lik...

Last post by AdmFubar - August 30, 2024, 10:23:50 PM

just write it like math formula  2 1/2 would be written as 2+(1/2) it will convert to decimal as 2.5 in the input field.

#60

Installation and Setup / Re: scribus on 4k display

Last post by AdmFubar - August 30, 2024, 08:25:01 PM

You might want to try installin kvantum. I have it on my machine, but I just swapped out my 2k display for a 4k one to test(tv), but my system doesnt see allow the hight resolution . prolly need a graphics processor other then the one on the board, so I'm not sure if it will allow the enlargment like i suspect.
see:
https://store.kde.org/p/1005410