Scribus Forums

Scribus => Text and Typography => Topic started by: eudoxos on July 19, 2017, 12:45:31 pm

Title: Clipping and skewing text
Post by: eudoxos on July 19, 2017, 12:45:31 pm
Hi there, in a peculiar case I would like to typeset text frame as usual, and only clip the result afterwards (the clipping should cut some letters, so not enough to make text shorter). As I understand, there is clipping path (different from contour line, which is used for text flow) only available with image frames, right? Another question is whether it is possible to skew text frame (not just rotate). In both cases I'd like the text to be editable. Otherwise I'd convert to paths and do it in inkscape. Thanks, cheers! vaclav
Title: Re: Clipping and skewing text
Post by: GarryP on July 19, 2017, 02:42:48 pm
For the first of your questions, I'm not sure what you want to do. I don't understand why you would want some of the letters to go missing. If you don't want the letters then it's usual to just not add them in the first place. I know you said it was a peculiar case but is there an example you could supply that would show people what you want? Even a simple scanned hand-drawn picture might help.

The clipping path of an image is only really used to control how text flows around that image. It's like a contour line but it's part of the image file and not a Scribus thing. The 'clipping' refers to the image rather than the text.

On your second question, you can skew the frame - by either using the Node Editor or via menu "Item -> Transform" - but the text will not be skewed along with the frame. To skew text you will have to convert it to outlines and then skew the resulting shapes. Unfortunately you won't be able to edit the text after converting to outlines so keep a backup of the original text if you need to try different things.

If you are experimenting then it might be good to put that specific piece of text into Inkscape first and then export different manipulated versions into Scribus until you get what you want but Scribus has plenty of vector tools so that's not usually necessary. Use whichever workflow is best for you.
Title: Re: Clipping and skewing text
Post by: eudoxos on July 19, 2017, 08:09:30 pm
>> the clipping should cut some letters, so not enough to make text shorter
Imagine a word which is vertically cut so that only lower parts of letters are visible. If this is not possible, it means the UI does not expose it, since cairo does have the capability of clipping any object (including text). What I finally did was to import SVG with white-out shapes and stick the text lower than the SVG. Not terribly elegant but works.
> via menu "Item -> Transform"
Yes, I tried that but it transforms the outline rather then the typeset result, as you say, which is both counter-intuitive (for text, at least) and not useful in this case. Some people suggested to use text on path for this, as workaround. This is for me unresolved, but I will try to do without it as the skew is not too big.

Title: Re: Clipping and skewing text
Post by: GarryP on July 20, 2017, 11:54:29 am
Ah, I think I understand now.

My attached image shows - from top to bottom reading downwards - (a) original text, (b) text cropped top and bottom, (c) text cropped by a shape. I assume you want to do something similar.

Scribus has no cropping functionality for text. Scribus always tries to render text as fully as it can, meaning that if it can't fully display a character it will not display it at all. One of the basic tenets of Scribus was to render text as well as possible. Cropping text does quite go against this.

Some cropping can be done on images but that's really just an artefact of having to put images into frames (except for vector art which is a different thing). Cropping sort of "comes for free" with image frames rather than it being a specific function.

I don't think it's as simple a case as the UI not exposing any cropping functionality available in Cairo. I rather suspect that it's much more complicated than that but I'm not interested in a discussion about the whys and wherefores. Scribus doesn't do it and the reason for that is up to the developers.

There are various ways to "crop" text in Scribus - depending on what effect you want - but the more complex techniques usually result in the text being non-editable. Sometimes you can just put a shape over the text, and you can even get the background to show through if you are careful. This keeps the text "intact". Sometimes, however, you have to convert the text into outlines and then manipulate those outlines in various ways. The original text is "lost". It really depends on the circumstances.

The Transform functions usually apply to frames/shapes and not the things inside the frames/shapes, except for rotation. I can see where this could be a bit counter-intuitive. I have no idea why there's a difference in functionality between some of the transforms in this context. It's just something that you need to learn and remember. Changing the functionality now could cause a lot of people a lot of problems.

One thing to remember is that Scribus is a DTP application and not an illustration application. It has a lot of illustration functions but it's never going to have them all, and it doesn't need to. As long as you can import things from other applications like GIMP, Inkscape and LaTeX then you can produce almost anything you want. You just might have to pop out to another application to get some of the more fancy stuff done.
Title: Re: Clipping and skewing text
Post by: a.l.e on July 21, 2017, 09:54:05 am
as far as i can tell, the problem is not what cairo can do and what the UI exposes but:

- what the scribus shapes can do and (most of all)
- what the pdf specifications allow.

as far as i know, (most) pdf versions do not allow clipping, so it makes little sense for scribus to work hard on getting a clipped object into scribus: at the end, it won't be able to correctly include it in the pdf.

on the other side, it would be wonderful if inkscape could resolve the clipping and export an svg that only contains the visible part of the svg...
or do you have evidences that say otherwise?
Title: Re: Clipping and skewing text
Post by: Nermander on July 21, 2017, 10:01:56 am
Yes, I was thinking that it mainly has to to with how glyphs are rendered in a PDF. A glyph is drawn by referring to the font, and in the font the glyph is complete. There is most likely no support in the PDF format to allow for only partially drawing a glyph.

I think the only way to solve this is to convert the text to outlines and clip the lines explicitly. Which our course means there is no good way of doing this dynamically.
Title: Re: Clipping and skewing text
Post by: GarryP on July 21, 2017, 03:27:31 pm
I use another application that allows clipping/cropping of anything - including text - and it can produce PDFs just fine so I don't think it's got anything to do with the PDF specifications. (See attached file for a very crude and quickly-knocked-together example.)

I'd say that this issue was more about how Scribus does what it does.
Title: Re: Clipping and skewing text
Post by: Nermander on July 21, 2017, 11:17:01 pm
In that PDF the text isn't really clipped, I can select text that is not visible, which I guess means it is printed beneath the overlay image.
Title: Re: Clipping and skewing text
Post by: GarryP on July 22, 2017, 11:21:39 am
Sorry, but I don't see what the problem is.

The only bits of the text that can be seen are the bits that are expected to be seen, the text is still editable in the application, and - as a bonus - the text is still selectable by the reader. Everyone wins.

There is no "overlay" image, the image is actually behind the shape that holds the text. The text is "inside" that shape. Any extra text that is there is purely because I was using sample text in a very crude way to show what is possible. Under normal circumstances any unwanted text would simply not be there in the first place.
Title: Re: Clipping and skewing text
Post by: a.l.e on July 22, 2017, 12:11:06 pm

i can easily reproduce your sample in scribus...
(see the attachment)

and scribus can easily import the pdf you have created and create the same output in a pdf
(see the other attachment)

what does this tell us?
technically, scribus could also have a clipping feature and resolve it in simple shapes when exporting to pdf (as your other application is doing).
it also seems to confirm that a pdf cannot contain the clipping information (otherwise scribus could not import your pdf)

on the other side, the fact that scribus does not support clipped images imported from svg is consistent with the idea that scribus only imports from SVGs what that it can easily export to valid PDF.

of course somebody could add a clipping "tool" to scribus and then allow the import of clipped content, but as you see in my sample, it's trivial to use the current scribus features to fake the same effect. so, there is probably little motivation (for now) to create such a tool.
on the other side, it would be really nice if inkscape could add an export to svg that removes all the information that is not needed when you only want to view the file (like in a browser or in scribus) or is not commonly supported in the svg viewers.

the flattening of transparencies is a similar (but probably way more complex to implement) case and, in the current state of the printing business, it's also a more urgent feature (but at the time scribus will have the flattening of transparencies in a stable version, all the print shops will probably correctly support the PDF versions that allows transparencies...)
Title: Re: Clipping and skewing text
Post by: GarryP on July 22, 2017, 02:50:16 pm
a.l.e, my point was that such a function is not bounded by the PDF specs (as alluded to by yourself and Nermander).

eudoxos asked about cropping a piece of text while keeping it editable but, as has been said, Scribus must always display the full glyph so that's not possible without resorting to using other objects as masks or converting to curves.

Converting to curves makes the text uneditable and using objects as masks is messy. What eudoxos wanted - from what I can tell - was a cropping function that kept the text intact and Scribus doesn't have one.

See attached - crudely done - video of how it could be implemented. Such a cropping tool could also work on SVGs (and images too but that's already done by the frame).
Title: Re: Clipping and skewing text
Post by: Nermander on July 31, 2017, 06:44:54 pm
Sorry, but I don't see what the problem is.

The problem may come when the PDF is sent to a RIP. The question is if the RIP can "undraw" the parts of the glyphs that shall not be visible.
Title: Re: Clipping and skewing text
Post by: GarryP on August 01, 2017, 05:13:59 pm
Ah, I see. I didn't realise that might be a problem. Thanks for pointing it out.

Can anyone confirm or deny this? Is this a real problem and, if so, is it inherent to the RIP process or does it depend on the individual machine?
Title: Re: Clipping and skewing text
Post by: Nermander on August 02, 2017, 10:49:20 am
I was thinking that the RIP draws glyphs based on the font data, and the font data does not tell where the glyph is to be clipped. For it to work the RIP must be able to convert each glyph to vectors and then clip those vectors at the clipping path to draw only the visible part of the glyph.

When drawing on screen you can overwrite part of a black glyph with a white object, but when printing you cannot "undraw" anything by overwriting it with white.
Title: Re: Clipping and skewing text
Post by: a.l.e on August 02, 2017, 11:19:07 am
i think this discussion is going in the wrong direction.

but i'm a bit reluctant in participating, since my two previous posts have been basically ignored and i don't have any hope that further explanations would be treated differently.

anyway, the attached pdf has been created with scribus and i'm pretty confident that every printer will print it correctly, with part of it erased.
that's not the issue.

the problem is not with getting this effect, but in getting it reliably and in an automatic way. independent from the context around it.

(and, yes, i still think that the best solution is to get inkscape to export an svg, where the text is converted to paths and cut at the visible boundaries. and inkscape should offer a similar export option for everything that cannot be directly converted to pdf.)
Title: Re: Clipping and skewing text
Post by: GarryP on August 02, 2017, 03:35:27 pm
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.
Title: Re: Clipping and skewing text
Post by: a.l.e on August 02, 2017, 08:09:34 pm
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
Title: Re: Clipping and skewing text
Post by: Nermander on August 02, 2017, 11:17:58 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).

Title: Re: Clipping and skewing text
Post by: GarryP on August 03, 2017, 02:45:04 pm
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.
Title: Re: Clipping and skewing text
Post by: Nermander on August 03, 2017, 09:14:06 pm
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?
Title: Re: Clipping and skewing text
Post by: Portreve on October 14, 2017, 05:37:28 pm
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.
Title: Re: Clipping and skewing text
Post by: dcpurton on July 07, 2018, 03:46:31 pm
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.
Title: Re: Clipping and skewing text
Post by: a.l.e on July 08, 2018, 07:31:52 pm
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.
Title: Re: Clipping and skewing text
Post by: dcpurton on July 10, 2018, 02:37:03 am

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:

Code: [Select]
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:

Code: [Select]
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.
Title: Re: Clipping and skewing text
Post by: dcpurton on July 10, 2018, 04:27:01 am
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).

Title: Re: Clipping and skewing text
Post by: dcpurton on July 10, 2018, 04:42:17 am
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.