I need to create a schema to pdf. This schema contains a lot of dashed lines. If I paint it like not dashed lines:
But if I try to paint it by using dashed lines will paints next:
Don't paint constant bar length and constant distance between bars. String example:
pdfItem.lineStyle(new RGBColor(color), 0.5, 1, 1,null, null, new DashedLine ([ 6 ]) );
pdfItem.moveTo(firstPoint.x, pointsOnY-firstPoint.y);
pdfItem.lineTo(secondPoint.x, pointsOnY-secondPoint.y);
pdfItem.end();
I think this is why lines in the schema composed of several shorter lines фтв and it affects the display if line is dashed.
How can I fix this trouble?
If you are going to paint a dotted-line rule, you should paint it in one operation from the start point to the end point of the line ray. Otherwise you can have various problems occur:
If you are attempting to concatenate segments together to form one longer dotted-line rule (i.e. without overlapping segments) each segment must end on a full increment of the first dot pattern, so that when the next generated dotted line begins after it, the eye will not see an error in spacing, or a dash that is too long.
Similarly, if your line segments do overlap for some reason, the start point of the new segment must align with the start point of a dash on the underlying segment, or again you will have dotted lines that are either of different gap spacing or, in a worst-case scenario, completely solid in appearance.
Related
For a recent project I've been working on a simple word processor, and because I need fine-grained control have had to implement a lot of the text shaping myself. Most of this is fairly straight-forward and described in detail places like here and here.
It's less obvious how to handle pressing down or up on the keyboard when dealing with non-monospaced text split across many lines. In monospaced text the algorithm is simple: move the text caret down one line and the same number of characters to the right that it was. But what about variable-width fonts? I've tried an algorithm like this (in pseudocode):
; Return text offset into next line after navigating down
function moveCaretDown():
Move text caret to start of next line
targetPixelOffset := previous pixel offset of caret in line above
textOffsetIntoLine := 0
pixelOffsetIntoLine := 0
prevDelta := Infinity
for each char in text of new line:
delta = abs(pixelOffsetIntoLine - targetPixelOffset)
; We are now further from the desired cursor offset than before, this must
; be closest slot to the caret's previous horizontal offset in this line.
if (delta > prevDelta):
return textOffsetIntoLine - 1
prevDelta = delta
pixelOffsetIntoLine += measureWidth(char)
currentOffset++
; Else return the offset of the last character in the line
return length of newline - 1
But I've found its behavior differs from text inputs in major web browsers and/or text editors (I can come up with some specific examples if needed). Is there some standard algorithm for this used by GUI toolkits or text shaping libraries? I was surprised I couldn't find a W3C standard on it, for example, considering this is behavior needed in every web browser.
* Inserting line breaks into a string at the correct places, handling ragged or fully-justified text, etc.
I don't think there's a standard other than to follow the Principle of Least Astonishment. Nowadays, that typically means seeing what the major applications do, since that will likely be familiar behavior to the user.
On the current line, you know the current horizontal offset. Let's call it x. I'm talking about the pixel position, not the number of characters or glyphs since the beginning of that line.
On the destination line, there is a set of horizontal offsets the caret can be placed (e.g., between glyphs). So you want to pick the one of those that's as similar to your current x as possible.
Furthermore, if the user moves the caret vertically several times in a row, you probably want to find the nearest to the original x. The caret may wiggle horizontally a bit as the user moves up and down, but you don't want it to drift. Once the user does something that intentionally changes the horizontal offset (e.g., inserts a character, uses a horizontal arrow, clicks the mouse, etc.) that's the best time to update x.
If you already have code to find the closest caret position to a mouse click, you might be able to re-use it as though the user had clicked the point exactly one line above or below the current x.
I've also seen some editors (including monospace text editors) that treat the end of the line as a special case. So if you move up or down when you're at the end of a line, you move to the end of the preceding or succeeding line. That seems a nice way to handle ragged right text and short lines at the end of a paragraph.
A line segment can be defined by a pair of points. There are well-known algorithms for finding whether two line segments in 2D space intersect. But what if we make it a bit trickier by adding a width to the line?
Imagine you have a line segment defined by a pair of points and a width. What you end up with is a rectangle whose sides are not necessarily aligned with the coordinate axes. (So you can't use the standard "rectangle overlap" functions.) What would be the best way to determine if two such line segments overlap?
I'd recommend to use The Method of Separating Axes to find out whether the rotated rectangles (thick line segments) overlap. This method is fast and simple.
A line with a width can be regarded as two parallel lines, separated by the width that you're talking about. So two lines which each have a width corresponds to four lines. Just work out whether any of these 4 lines intersect and you're done, aren't you?
Update: A comment points out that this will miss overlapping parallel lines. I think that's all it will miss, so that case could be handled as a special case.
I'm developing a simple a graphical editor for my flash-based app. In my editor there's a posibility of scaling, range of scaling is big (maximum scale is 16.0, minimum scale is 0.001 and default scale is 0.2). So it's quite possible that a user can draw a line with thickness 0.1 or 300.0, and it looks that line possible thickness (in Graphics.lineStyle()) has upper border. As I found out from livedocs maximum value is 255. So if thickness is greater then 255.0 there'is drawn a line of thickness 255.0. Whether mentioned upper border exists and how big is it. Here're my questions:
Right now I'm drawing lines with drawPath() or lineTo() methods. Natural walkarround if thickness is greater then 255.0 is to draw a rectange instead of segment and two circles on the ends of segment (instead of lineTo()). Or even to draw two thin segments and two half-circles and fill interior. Maybe there's more elegant/quick solution?
Another question is if the thickness of line is big but less then 255.0 (e.g. 100.0), what is faster drawing a line with lineTo() or drawing two thin segments and two half-circles and fill interior?
And finally, maybe someone knows a good article/book where I can read what's inside all methods of flash.display.Graphics class (or even not flash specific article/book on graphics)?
Any thoughts are appreciated. Thank you in advance!
I agree with f-a that putting the line in a container would probably be better and more efficient than drawing a rectangle and extra circles.
I don't think that the math would be too difficult to work out. For efficiency you should probably only do this if the line style is going to be over 255.
To setup the display object to hold your line I would start by halving the width of your line (the length can stay the same). Then create a new sprite and draw the line in the sprite at half size (e.g. if you wanted 300, just draw it at 150). It would be most simple to just start at (0,0) and draw the segment straight so that all of your transformations can be applied to the new sprite.
From here you can just double the scaleY of the sprite to get the desired line weight. It should keep the same length and the ends should also be rounded correctly.
Hope this helped out!
A cool resource for working with the graphics class is Flash and Math. This site has several cool effects and working examples and source code.
http://www.flashandmath.com/
I would like to draw a multiple segment line on a html 5 canvas with variable width per segment.
I tried something like (pseudocode):
beginpath()
setLineWidth(1)
lineTo(0,0)
...
setLineWidth(10)
lineTo(73, 44)
stroke()
but it seems stroke only takes the last linewidth() value? Is there another way?
I tried making every segment its own line, but that turned out really really show when drawing 1000+ segments.
You have to call stroke() on each segment, not at the very end and there is no other possiblity.
Probably will have to make each segment it's own line. That or figure out how to make a custom shape with the same sort of gradient.
I'm drawing line graphs on a canvas. The lines draw fine. The graph is scaled, every segment is drawn, color are ok, etc. My only problem is visually the line width varies. It's almost like the nib of a caligraphy pen. If the stroke is upward the line is thin, if the stroke is horizontal, the line is thicker.
My line thickness is constant, and my strokeStyle is set to black. I don't see any other properties of the canvas that affect such a varying line width but there must be.
Javascript:
var badCanvas = document.getElementById("badCanvas"),
goodCanvas = document.getElementById("goodCanvas"),
bCtx = badCanvas.getContext("2d"),
gCtx = goodCanvas.getContext("2d");
badCanvas.width = goodCanvas.width = badCanvas.height = goodCanvas.height = 300;
// Line example where the lines are blurry weird ect.
// Horizontal
bCtx.beginPath();
bCtx.moveTo(10,10);
bCtx.lineTo(200,10);
bCtx.stroke();
//Verticle
bCtx.beginPath();
bCtx.moveTo(30,30);
bCtx.lineTo(30,200);
bCtx.stroke();
// Proper way to draw them so they are "clear"
//Horizontal
gCtx.beginPath();
gCtx.moveTo(10.5,10.5);
gCtx.lineTo(200.5,10.5);
gCtx.stroke();
//Verticle
gCtx.beginPath();
gCtx.moveTo(30.5,30);
gCtx.lineTo(30.5,200);
gCtx.stroke();
// Change the line width
bCtx.lineWidth = 4;
gCtx.lineWidth = 4;
// Line example where the lines are blurry weird ect.
// Horizontal
bCtx.beginPath();
bCtx.moveTo(10,20.5);
bCtx.lineTo(200,20.5);
bCtx.stroke();
//Verticle
bCtx.beginPath()
bCtx.moveTo(50.5,30);
bCtx.lineTo(50.5,200);
bCtx.stroke();
// Proper way to draw them so they are "clear"
//Horizontal
gCtx.beginPath();
gCtx.moveTo(10,20);
gCtx.lineTo(200,20);
gCtx.stroke();
//Verticle
gCtx.beginPath();
gCtx.moveTo(50,30);
gCtx.lineTo(50,200);
gCtx.stroke();
HTML:
<h2>BadCanvas</h2>
<canvas id="badCanvas"></canvas>
<h2>Good Canvas</h2>
<canvas id="goodCanvas"></canvas>
CSS:
canvas{border:1px solid blue;}
Live Demo
My live demo basically just recreates what the MDN says. For even stroke widths you can use integers for coordinates, for odd stroke widths you want to use .5 to get crisp lines that fill the pixels correctly.
From MDN Article
If you consider a path from (3,1) to (3,5) with a line thickness of
1.0, you end up with the situation in the second image. The actual
area to be filled (dark blue) only extends halfway into the pixels on
either side of the path. An approximation of this has to be rendered,
which means that those pixels being only partially shaded, and results
in the entire area (the light blue and dark blue) being filled in with
a color only half as dark as the actual stroke color. This is what
happens with the 1.0 width line in the previous example code.
To fix this, you have to be very precise in your path creation.
Knowing that a 1.0 width line will extend half a unit to either side
of the path, creating the path from (3.5,1) to (3.5,5) results in the
situation in the third image — the 1.0 line width ends up completely
and precisely filling a single pixel vertical line.
If linewidth is an odd number, just add 0.5 to x or y.
I just solved a problem of a similar nature. It involved a bug in a For loop.
PROBLEM: I had created a for loop to create a series of connected line segments and noticed that the line was thick to start but thinned out significantly by the final segment (no gradients were explicitly used).
FIRST, DEAD END THOUGHT: At first I assumed it was the above pixel issue, but the problem persisted even after forcing all the segments to remain at a constant level.
OBSERVATION: I noticed that I made a newbie's mistake -- I only used a single "ctx.beginPath()" and "ctx.moveTo(posX,posY)" PRIOR to the For loop and a single "ctx.stroke()" AFTER the For loop and the loop itself wrapped a single ctx.lineTo().
SOLUTION: Once I moved all methods (.beginPath(), .moveTo(), .lineTo() and .stroke()) together into the For loop so they would all be hit on each iteration, the problem went away. My connected line had the desired uniform thickness.
Try lineCap = "round" and lineJoin = "round". See "Line Styles" in this PDF to see what these parameters do.
Edit 17-July-2015: Great cheat sheet, but the link is dead. As far as I can tell, there's a copy of it at http://www.cheat-sheets.org/saved-copy/HTML5_Canvas_Cheat_Sheet.pdf.