Clipping and skewing text

Previous topic - Next topic

eudoxos

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

GarryP

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.

eudoxos

>> 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.


GarryP

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.

[attachment deleted by admin]

a.l.e

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?

Nermander

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.

GarryP

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.

[attachment deleted by admin]

Nermander

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.

GarryP

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.

a.l.e

#9
garry,

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...)

[attachment deleted by admin]

GarryP

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).

[attachment deleted by admin]

Nermander

Quote from: GarryP on July 22, 2017, 10:21:39 AM
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.

GarryP

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?

Nermander

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.

a.l.e

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.)

[attachment deleted by admin]