View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0016137 | Scribus | Graphics / Image Frames | public | 2020-06-15 12:15 | 2020-06-19 08:14 |
| Reporter | spaceChRiS | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | new | Resolution | open | ||
| Product Version | 1.5.4 | ||||
| Summary | 0016137: Add option to always fill image frame | ||||
| Description | Currently there is the option “to frame size” to scale an image to a frame, and the option “proportional” to keep the image proportion. Using the two together results in a non-filled frame. It would be great to have another option “entirely fill frame” to make sure the whole frame is filled entirely but the image proportions are kept intact. With the option selected, it would not be possible to reposition an image in a frame such that part of the frame are empty. For me this is the major use case of image frames. Imagine a calendar with landscape full frame images. The layout in this case is fix, and it is reasonable to entirely fill the frame and not leave any blanc space. However, paper format and image format often differ slightly (e.g. image 1:1.5 vs paper 1:1.41). This requires to find a reasonable crop of the image that fills the frame. This can be achieved by setting the scale factors and the position, but this is cumbersome, failure-prone and not exact. Scripting helps a bit with resizing (see https://wiki.scribus.net/canvas/Fitting_an_Image_to_its_Frame), but still you have to move the image around in the frame. This often leads to little errors at the edges (see e.g. figure 5 in the attached pdf). An option to keep the frame filled no matter what would be extremely helpful. For implementation, it may be the most simple solution to clamp the values of the position entries between [frame_width-image_width, 0] and [frame_height-image_height, 0] if the option is checked. As the image is aligned in the upper left corner, this may give the correct range of position shifts. Explanation of the attached pdf: 1 - Image after dropping it into the frame does not fit in any dimension. 2 - “To frame size” option distorts the image - undesired for photographs. 3 - “proportional” solves the distortion, but does not fill the frame. 4 - Running the script mentioned above results in the correct size, but one has to reposition the image. 5 - I often get errors at the edges when repositioning (the example is exaggerated, and typically it happens if the aspect ratios are close and it then happens typically at the other side). 6 - Desired result - this would be easier with the feature described above implemented. | ||||
| Tags | No tags attached. | ||||
| Patch | No | ||||
|
|
|
|
|
Related issues are: * https://bugs.scribus.net/view.php?id=6230 * https://bugs.scribus.net/view.php?id=5662 * https://bugs.scribus.net/view.php?id=13561 |
|
|
here are two tickets with patches: - https://bugs.scribus.net/view.php?id=15448 - https://bugs.scribus.net/view.php?id=15560 they have been waiting one and a half year for a review... |
|
|
Thanks for looking into this. Regarding the mentioned tickets: 15448: If I understand it correct, this is exactly the opposite of what I suggest here. 15560: I think this is identical to my suggestion. Thanks for pointing it out, I did a research but did not find this particular one. Does your patch implement the scaling in? This would be great. For which version is the inclusion of your patch planned? Any idea how to proceed? Should I close my issue as it is a duplicate? 15560 seems the real duplicate, the one mentioned by jghali is related. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-06-15 12:15 | spaceChRiS | New Issue | |
| 2020-06-15 12:15 | spaceChRiS | File Added: screenshots.pdf | |
| 2020-06-15 12:21 | spaceChRiS | Note Added: 0047696 | |
| 2020-06-15 13:12 | jghali | Relationship added | has duplicate 0015437 |
| 2020-06-16 06:44 | ale | Note Added: 0047699 | |
| 2020-06-18 21:53 | spaceChRiS | Note Added: 0047705 | |
| 2020-06-19 08:14 | JLuc | Relationship added | related to 0015448 |
| 2020-06-19 08:14 | JLuc | Relationship added | duplicate of 0015560 |
