Clipping and skewing text

Previous topic - Next topic


Nermander: I think I understand what the issue could be now, I just think it would be good to get some kind of confirmation - or otherwise - from someone who regularly uses (or owns) a RIP rather than just letting the possibility of a problem hang in the air. (Don't all laser printers use a RIP?)

Personally I don't really care because I don't usually get anything printed but I still think it would be nice to know what the actual situation was.

a.l.e: Why do you think the discussion is going in the wrong direction? The OP asked about cropping text and that's what is being discussed.

Also, why would the best solution be for the user to have to go into Inkscape just to crop some text. Surely the best solution - for a user of Scribus - would be for Scribus to have the necessary functionality?

I don't think you're being ignored as I've mentioned your suggestions in various places. You mentioned that the PDF specs might not allow for cropping but it certainly seems to do so (see below). You mentioned modifications to Inkscape for SVGs but I didn't think that was particularly relevant to the OP's issue. You mentioned a possible Scribus clipping tool but said that it probably wouldn't be implemented so I didn't see any real reason for pursuing that matter any further.

I think there are three main questions that come from the OP's original post:

Q1. Can Scribus crop text?
A1. No. There are tricks to make it look like it can but they're just tricks.

Q2. Does the PDF specification allow for cropping of text?
A2. It certainly seems to - see attached example - but it's possibly achieved by some sort of mask. Either way, it seems to allow what the user wants as far as PDF production for on-screen-use goes. (And, as can be seen by the giraffe, it looks like SVG cropping is fine too.)

Q3. Do RIPs produce expected output when printing cropped text?
A3. I don't have an answer, but it's reasonable to expect that they should. If a RIP can't print all PDFs then it's probably not a very good (or up-to-date) RIP. If you can put it in a PDF then a RIP should be able to print it (obviously there are areas such as special inks that might be an issue but the geometry should be precise). It would be good to know either way.

All in all, I think the OP's question has been answered, and it's: "No, Scribus can't crop text". The discussion has now moved away from Scribus - because Scribus can't do what the OP wanted - and into a more general area. All that is left now is to try and find out if cropped text in a PDF is printed properly on RIPs.

[attachment deleted by admin]


hi garry,

indeed, scribus does not have a clipping tool, but as you might have seen in the pdfs i've uploaded, it is possible to manually clip content.
you can probably have quite complex forms (and in most cases it's not really difficult to do, if you know well scribus)

on the other side, you might have missed the pdf i've uploaded with the pdf generated from scribus after having imported the pdf generated by the other software you're using. (that was a sentence...)

in that pdf you will see that the clipping information is probably not in your pdf file: your software is "flattening" the clipped area and scribus can then import and again export the clipped text.

which would confirm that the pdf standard does not support clipped areas.

but, even if scribus does not have a clipping tool, you can clip the text by putting it behind a mask (which is also what your software is then doing, when exporting to pdf).
the issue for scribus is to correctly and automatically create that mask.
which might be hard to do (and is probably a close problem to flattening transparencies)

concerning the RIPs: it's a bit of a non-question... if it cannot be in a pdf, well, there is no way scribus can produce a clipped content for print... or do you see a way?

finally, of course being able to clip content in scribus would be an interesting feature, but one that would probably not be used that often.
i still think that it's better to implement it in a vector drawing program (and correctly export it)
personally, i've never heard of anyone having a real need for it... except for people having issues when importing svg files.

have a nice evening


Quote from: a.l.e on August 02, 2017, 07:09:34 PM
indeed, scribus does not have a clipping tool, but as you might have seen in the pdfs i've uploaded, it is possible to manually clip content.
I don't consider the content in those PDFs to be clipped. I'd rather say it is transparency (but with 100% opacity) (since the non-visible text is still selectable in the PDF).


I would be quite happy to drop this subject as it's not really relevant to me. It's just interesting is all.

Saying that, I would like to add a few opinions and observations that might help future discussions.

Cropping can be a very useful feature but I agree that it wouldn't be used much for text. If someone wants to crop text then they're normally trying to create something fancy where the text glyph forms would need further manipulation so converting them to outlines would probably be needed anyway. I can't think of an example where I have needed to crop text within a rectangle and not then went on to do other manipulations. As a possible addition to Scribus I would say that text cropping is a low priority.

It looks like I was wrong and text cropping isn't actually something that's allowable in a PDF but masking does the same thing as far as on-screen use is involved. As for printing, that's really outside my sphere of knowledge (which is why I was asking for confirmation/denial earlier) so I'm happy to leave that to other people to discuss.

Cropping vector graphics - on the other hand - can be very useful if, for example, you have a "sheet" of logos/icons in a single SVG and you just want to display one of them. (Sometimes people create collections of things together on the same drawing so they can make sure all of the things have the same look and feel without having to switch between different drawings. And you can change the icon/logo just by moving the "sheet" around under the crop boundary.)

However, there would be an issue over what happens to the parts of the drawing that can't be seen. For "true" cropping I would say that the unseen parts of the drawing should not be exported to the PDF but there's the problem of what happens to vectors which cross the crop boundary. Some kind of very clever vector subtraction processing could be applied but I think that might be overkill and a transparency mask might be easier, but then there's the transparency/flattening issue that's been raised.

Again, for me, it's not a big issue. I don't crop vectors very much and when I do need to I also normally have to make other changes so I generally do what changes I need using the same tools without cropping.

Cropping raster images is a much more useful function as "true" cropping would mean smaller PDF sizes where a 'sub-image' was exported rather than the whole thing. This is an area that has been brought up in the past but I've a feeling it would mess with how Scribus draws images. For instance, Scribus "crops" images inside image frames but they're not really cropped, the whole image is exported but only part of it is shown. Sort of "cropping lite". Adding a "true" cropping function might make things more awkward UI-wise.

All in all, I don't have any real stake in adding cropping functionality to Scribus as I wouldn't use it much, except for raster cropping and that can be done in GIMP if it's really needed anyway. I just thought Nermander had raised an interesting issue about cropping text that needed some kind of answer.


I just want to add that I have not (as far as I know) said that there certainly is a problem, but that there could be.

Because my interpretation is that when rendering a PDF the "cursor" is placed and then a glyph drawn using the font data. Of the full glyph shall not be drawn, how is the rendering engine informed of that? It must mean there needs to be an on the fly "reshaping" of the glyph before it is drawn?


I would like to echo some of the comments up-thread. Scribus is a desktop publishing program first and foremost, and not some kind of effects package. Classically, standard desktop publishing programs (and my memory is long enough to stretch back as far as Springboard Publisher, Aldus PageMaker, etc.) have relatively limited ranges of effects they can apply to type, the idea of which being they are designed for layout functionality, and doing all kinds of stuff to type falls much more under the heading of graphics software. I know that in more recent times, Adobe InDesign has somewhat blurred the lines here, but even it has its limits, and requires one to use other software, like Photoshop or Illustrator, etc., and then one can import that object as an image.

I'm not per-se against Scribus having extended graphical capabilities. There are times when it would be nice if it also did some of the stuff InDesign does, but I'm not going to ask Scribus' developers to turn it into another iteration of, for example, Inkscape.

Now, all that said, I'm also old enough to remember some utility software we used to have in Mac OS which would do type effects by way of taking the initial text you were interested in (for example, a business name) and parameters of what you were interested in doing (drop shadows, mirror reflections, etc.) and then sending that to a network-attached, PostScript-capable laser printer for rendering, and then returning the finished data to the user as an image which could be saved as an EPS or a TIFF. (Yes, I do go back a fair bit...) I also remember latter generations of that sort of graphics utility software being able to apply the effects through local processing (i.e. on the computer you were using) because by then Adobe had released PostScript to the extent that others could make use of it.

Getting to the point raised here originally by eudoxos, I would think the best-practices way to do what you're trying to is to use Scribus to set the initial text you want at a large enough size that it will be easily worked on by you, then convert that text to outlines, export that page to SVG and open it in InkScape, do whatever it is you want to do with it and save it in there, then import the resulting object back into Scribus and place it into your layout however it is you see fit. That's how I would do it, anyway.


Just came across this thread while investigating Scribus' handling of clipping. There's a lot of misinformation here... So just for others who come across it.

Firstly, the PDF spec *definitely* includes clipping (See section 4.4.3 of version 1.7 of the spec). It was present in PostScript Level 1 and is present in all PDF versions. This also answers the RIP questions above. All RIPs support clipping.

Clipping doesn't do anything magical, all it does is limit any drawing operation to within the current clipping path. The default clipping path is the whole page. You can clip to any path or even text outlines (though the method is slightly different).

Here's a very simply PostScript file that shows how clipping works:

100 100 moveto
200 100 lineto
200 200 lineto
100 200 lineto
/Times-Roman findfont
25 scalefont
90 150 moveto
(Clipped text) show
150 150 60 0 270 arc

This shows both an arc and some text clipped to a rectangle.

Secondly, Scribus does not support applying clipping paths. But it can import files like this. Sort of.

Curiously, Scribus' handling of files like this (both PS and PDF) is a buggy and inconsistent.

Scribus 1.4.7 can import the above PS file and open it directly correctly. As soon as you ungroup the object the clipping path is lost.

Scribus 1.5.5 svn can open it directly OK, but fails when you try to import it (via File menu). In the latter case, nothing is clipped. More complex clipping examples (e.g., with nested clipping; clipping to complex paths) fail in other ways even when opening directly.

My own view is that Scribus should definitely be able to import such files without getting it wrong. And it probably should include such a clipping tool too.

Clipping isn't an advanced graphics feature, it's a basic feature that should be included in any application that can manipulate text and graphics. This is reflected in the fact that clipping is a core feature of PostScript and PDF.


very interstingd cpurton!

from my side:

- i did not know that pdf supports clipping (of course i knew about clipping bitmaps).
- i don't think that the ps round trip is nowadays really interesting (when programming resources are scarce), but -- if what you write is correct -- scribus should import and export clipping areas in the pdf workflow.
- can you provide an example with text or vectors clipped in a pdf?
- do you have the skills (or you know somebody with the skills) to implement it for scribus?
- and, of course, it should also work when importing svg files...

also, since scribus does not support clipping in the pdf output, it does not support it either for its own shapes (except for bitmap images: that's why it works when you load a pdf in an image frame: it will then be (mostly) treated as a bitmap image).

if somebody can and wants to work in this, we should open a ticket in with a feature request and track there the work to be done.



I just used PostScript as my example file because it's easy to write by hand and read and see what is going on. You can convert that file to PDF using Ghostscript and it will contain the same clipping path, text and arc.

If you do this and uncompress the PDF the relevant PDF object looks like this:

7 0 obj
/Length 271
q 0.1 0 0 0.1 0 0 cm
/R7 gs
1000 1000 1000 1000 re W n
0 g
10 0 0 10 0 0 cm BT
/R8 25 Tf
1 0 0 1 90 150 Tm
(Clipped text)Tj
10 w
0 G
2100 1500 m
2100 1831.37 1831.37 2100 1500 2100 c
1168.63 2100 900 1831.37 900 1500 c
900 1168.63 1168.63 900 1500 900 c


q and Q are equivalent to gsave and grestore.

W sets the clipping path. The clipping rectangle is set:

1000 1000 1000 1000 re W n

i.e., a rectangle starting at (1000, 1000) with width (1000,1000). n stands for no-op. It means the path is neither filled nor stroked.

You can also see that the string "Clipped text" is in the PDF, even though it is clipped when displayed.

I also attached clipping.pdf which was converted from in my previous post. You could also import this into Inkscape and then ungroup and release the clip to reveal the three objects.

There is also *some* support for this in Scribus. As I said in my previous post, you can open the PDF directly (e.g., from commandline: scribus clipping.pdf) and the clipping path is preserved. You can then happily export it to PDF from within Scribus and the clipping path will continue to be preserved in Scribus' PDF export.

Note that this is *not* imported into an image frame. You can ungroup the arc and circle and confirm this (although you will lose the clipping path).

No PDF clipping path is preserved if you import the PDF into an existing document using File→Import...→Get Vector File... I find this surprising!

Support for the PostScript version is *better* in 1.4.7 than in 1.5.5svn. It works both opening directly and importing via file menu. 1.4.7 does not importing PDFs this way, of course.

I have already submitted a bug at but this was before I realised that the issues were more complicated.

I *may* be able to look at this issue. But my skills are more at the level of fixing bugs, rather than implementing clipping properly in Scribus for its own objects which is what I think needs to happen first before issues with import from PDF, PS, and SVG are dealt with.

[attachment deleted by admin]


Just to show this in Scribus, here's a screenshot of clipping.pdf opened (correctly clipped). And showing what happens when you ungroup this object.

For the record, you can import SVG files (via File menu) with clipping and they also display correctly (but still can't be ungrouped without losing the clipping path).

[attachment deleted by admin]


One other point of misunderstanding to clear up in this thread is that clipping occurs at the point when the object is *rasterised*. i.e., no where does PostScript or PDF or any drawing program calculate a new path for a clipped object based on the clipping path.

You *can* do this of course. You can find the union or intersection of two paths in Inkscape, for example.

Clipping is a core feature of video cards and graphics APIs (e.g., OpenGL) as well.