-draw two rectangles, adjacent on one side. -fill them with the same hatching (for example 45° hatching) The hatching lines are not continuous between the two rectangles. This problem occurs for all kind of shape. To hatch a complex shape, it is sometimes possible to decompose it into several simple adjacent shapes, and to hatch each simple shape. With Draw, it is not possible due to this discontinuity. A possible solution : I suppose that the hatching is located from a point of the shape. The hatching continuity would be guaranteed if the hatching is located from a point of the page : all the hatchings would have the same reference point. thanks to consider this request.
I'd say WONTFIX because of the spacing property which makes it impossible to perfectly fit the hatching like a pattern. Unfortunately this option doesn't help you because of #94761 (blurry pattern bitmaps).
I'm not sure to understand : my pb is not a pb of blurry pattern, or a pb of spacing between lines. It is a pb of position of hatching. If all the hatching are drawn from a common reference (linked to the page for example), then they would be continuous. But maybe the hatching position is not yet controlled, in this case, my ask would be complex to implement.
No, hatching currently is an attribute implemented individually against the frame of each draw object. We probably should not change that from default. Enhancement required would be the ability to apply the "hatching" to the entire draw canvas and then mask against that. Objects would be set transparent to show the contiguous hatch. Another possibly might be to extend draw objects to inherit the attribute of the canvas's background frame (if ODF can consistently accommodate it). And, could envision a use case where multiple background hatch fills might be required--extending and inheriting from a pick list of full canvas backgrounds. But with either approach, believe there would need to be work on polygon object intersections for performing the masking. The issue has come up in handling PDF import where hatching layer(s) are masked to expose fill pattern(s) inside objects. =-ref-= See bug 84032 - Intersection of some polygons produces wrong result See bug 86211 - PDF Import: clipping is not implemented
(In reply to V Stuart Foote from comment #3) > No, hatching currently is an attribute implemented individually against the > frame of each draw object. We probably should not change that from default. So close this ticket? > But with either approach, believe there would need to be work on polygon > object intersections for performing the masking. The issue has come up in > handling PDF import where hatching layer(s) are masked to expose fill > pattern(s) inside objects. Or keep it?
Keep it, it is a reasonable enhancement to performing the "hatching" of Area fills. IIUC, somewhat complex to implement. I think Armin had done some of the needed primitives work on it with his aw80 work. Also affects fidelity of PDF import--layers providing a common hatched fill clipped by objects are frequent. Stuart -> Hieko: probably not too related to the Draw bitmap pattern fill selections from Gallery--assign to a different meta?
(In reply to V Stuart Foote from comment #3) Well, I neer to echo xjldu-libreoffice@yahoo.fr: I'm not sure I understand the stated difficulties/objections... > No, hatching currently is an attribute implemented individually against the > frame of each draw object. We probably should not change that from default. AFAICT, the request is not related to this specific aspect. Currently, the canvas doesn't have the "global" hatching, but that's not required to implement the request. > Enhancement required would be the ability to apply the "hatching" to the > entire draw canvas and then mask against that. Objects would be set > transparent to show the contiguous hatch. Actually, this *could* be implemented that way. Or not. I see it this way: there is a pre-defined hatching origin point (0,0), and a switch if the point is object-relative, or paper-relative. The information is kept in each object individually, and is adjustable using area dialog page. Hatching/filling/gradient functions would then be tweaked to take this data into account: e.g., first stage is to find where the hatching starting point is WRT the shape itself: if it's object-relative, it's simple, otherwise, current shape position offset is considered -> the point is found. Then, first of parallels will be started at specified point; others will be drawn relative to it. Currently, already present analogous setting is e.g. angle of hatching. Moreover, the Center X/Center Y of gradient fills is highly related. > But with either approach, believe there would need to be work on polygon > object intersections for performing the masking. The issue has come up in > handling PDF import where hatching layer(s) are masked to expose fill > pattern(s) inside objects. I'm not sure it's needed. Imo, if implemented properly, then no other change of logic is required...
If hatch sould be globally anchored is unclear - in ancient times, it was just a technical coincidence due to limited possibilities. Nowadays each shape anchors it's hatch at (0,0) as mentioned. Of course this could easily be changed in drawing, but: - Where to put t5hat attribute in the shapes? - in the file format? - does ODF have an attribute for it? - How will overlapping objects look when hatch is drawn twice (AAed lines will not just look 'unchanged' it will be visible that they were painted twice) -> Conclusion: Handling painting is the least doable part of such a change (unfortunately).