Activity for Angus Johnson
-
Angus Johnson posted a comment on ticket #23530
Thank you for your assistance, I'll contact my ISP.
-
Thanks. See attached. I tried both udp and icmp using my broadband network and it times out after a few hops. I guess this suggested a faulty routing table and i should contact my isp? (The second OK trace was using my mobile phone's network.) Cheers A.
-
Additional info: I'm running Windows 10 (Version 21H1 OS Build 19043.1706) and did recently update to this build. I can confirm there is no proxy server on the PC and the home router uses no proxy. I've even tried with Windows Firewall disabled without success. I've also just checked this on another PC (using the latest version of Git for Windows): vlmj1@DESKTOP-XXXXXXX MINGW64 /c/temp $ git clone https://angusj@git.code.sf.net/p/image32/code tmp Cloning into 'tmp'... fatal: unable to access 'https://git.code.sf.net/p/image32/code/':...
-
Additional info: I'm running Windows 10 (Version 21H1 OS Build 19043.1706) and did recently update to this build. I can confirm there is no proxy server on the PC and the home router uses no proxy. I've even tried disabling Windows Firewall without success. I've also just checked this on another PC (using the latest version of Git for Windows): vlmj1@DESKTOP-XXXXXXX MINGW64 /c/temp $ git clone https://angusj@git.code.sf.net/p/image32/code tmp Cloning into 'tmp'... fatal: unable to access 'https://git.code.sf.net/p/image32/code/':...
-
Additional info: I'm running Windows 10 (Version 21H1 OS Build 19043.1706) and did recently update to this build. I can confirm there is no proxy server on the PC and the home router uses no proxy. I've even tried disabing Windows Firewall without success. I've also just checked this on another PC (using the latest version of Git for Windows): vlmj1@DESKTOP-XXXXXXX MINGW64 /c/temp $ git clone https://angusj@git.code.sf.net/p/image32/code tmp Cloning into 'tmp'... fatal: unable to access 'https://git.code.sf.net/p/image32/code/':...
-
Hi SF Support. Thank you for your timely help. We don't see any problems with our services. OK. I accept that the problem is likely at my end. You are probably behind a firewall or using a proxy. No, I'm pretty sure I'm not. Please try using HTTPS: $ git clone https://angusj@git.code.sf.net/p/image32/code tmp Cloning into 'tmp'... fatal: unable to access 'https://git.code.sf.net/p/image32/code/': Failed to connect to git.code.sf.net port 443: Timed out
-
Additional info: I'm running Windows 10 (Version 21H1 OS Build 19043.1706) and did recently update to this build. I've rechecked the local firewall and the home router uses no proxy. I've even tried disabing Windows Firewall, all without success. I've also just checked this on another PC (using the latest version of Git for Windows): vlmj1@DESKTOP-XXXXXXX MINGW64 /c/temp $ git clone https://angusj@git.code.sf.net/p/image32/code tmp Cloning into 'tmp'... fatal: unable to access 'https://git.code.sf.net/p/image32/code/':...
-
Hi SF Support. Thank you for your timely help. We don't see any problems with our services. OK. I accept that the problem is likely at my end. You are probably behind a firewall or using a proxy. No, I'm pretty sure I'm not. Please try using HTTPS: $ git clone https://angusj@git.code.sf.net/p/image32/code tmp Cloning into 'tmp'... fatal: unable to access 'https://git.code.sf.net/p/image32/code/': Failed to connect to git.code.sf.net port 443: Timed out ps: I'm running Windows 10 (Version 21H1 OS...
-
Hi SF Support. Thank you for your timely help. We don't see any problems with our services. OK. I accept that the problem is likely at my end. You are probably behind a firewall or using a proxy. No, I'm pretty sure I'm not. Please try using HTTPS: $ git clone https://angusj@git.code.sf.net/p/image32/code tmp Cloning into 'tmp'... fatal: unable to access 'https://git.code.sf.net/p/image32/code/': Failed to connect to git.code.sf.net port 443: Timed out
-
No longer able to access my project using git
-
Renamed Img32.Clipper to Img32.Clipper2 to rectify issues with XE4 compiler.
-
Evidently XE4 mis-handles the file naming namespaces which is surprising as both older and newer compilersdon't have this problem. I'm not keen on renaming Clipper.pas so I'll probably rename Img32.Clipper.pas to Img32.Clipper2.pas.
-
OK, I've once again amended Img32.Clipper. Hopefully it'll compile for you this time. 🤞
-
Fixed bug compiling Img32.Clipper (#24)
-
I'm confident I've found and fixed the problem you were encountering. A couple of the Clipper library source files had acquired unicode byte marks which I've now removed. I've also rechecked pretty much everything including the samples and it compiles without issues for me in both Delphi 7 and Delphi 10.4
-
Fixed problem with unicode byte marks in source
-
Added compiler directive to optionally disable storage streams
-
Hi Edwin. Yes, Clipper has recently undergone massive change and I'm now in the process of rechecking its integration into Img32.
-
Updated Clipper library
-
Nevermind, I've just about finished translating it myself.
-
Clipper2 is just about finished now (at least in Delphi and C# languages), and all that's needed (except for any late bugfixes) is a documentation update. However I'm keen to host a C++ translation just as I have for Clipper1 here. But this time I'm hoping to find someone very proficient in C++ that would be willing to do at least the basic translation of Clipper2. If you're interested and might be able to help, please contact me over on GitHub. Thanks, Angus
-
Hi again Ralf. Thanks for reporting this. I'll fix it in the next upload. (That might be a few more days as I'm currently occupied with merging touching polygons in clipping solutions. I've had many attempts at this - to do it relatively simply and without a significant performance load - but this time I think/hope I've finally got it nailed.) Clipper2Lib issues should probably go to Github. Yes, I'd prefer all Clipper2 feedback here please.
-
Sorry, I missed your earlier comment re BMP file headers. Yes TImageFormat_BMP.SaveToStream intentionally omits the file header because they are only required when saving to file streams, and the TImageFormat_BMP.SaveToFile function does include the file header. However, when saving to other streams, eg BMP resource streams, the file header is not required and can cause problems. If you really need the file header in a 'non-file' stream, then you'll need to manually copy the header into the stream...
-
BMP & GIF problem
-
Img32.Fmt.Gif
-
Top spacing seems too big
-
Text overflows bounding rect
-
Experimental Img32.Ctrls demo don't work on French Windows
-
Compile fatal error on BDS2006
-
AV in the depths of Img32 modules.
-
Hi Vad. This is your problem .... FontReader.Load('Courier'); This isn't a TrueType font and Image32 only reads TrueType fonts. Change the line to ... FontReader.Load('Courier New'); and your chart will look just fine.
-
Hi Vad. This is your problem .... FontReader.Load('Courier'); This isn't a TrueType font and Image32 only reads these fonts. Change the line to ... FontReader.Load('Courier New'); and your chart will look just fine.
-
Hi Hafedh. Thanks for the feedback, and I've verified that that this is indeed a bug. Hopefully this will work ... procedure TImageFormat_GIF.SaveToStream(stream: TStream; img32: TImage32); var gif: TGIFImage; bmp: TBitmap; begin bmp := TBitmap.Create; gif := TGIFImage.Create; try //copy to the new TBitmap bmp.PixelFormat := pf32bit; bmp.SetSize(img32.Width, img32.Height); bmp.AlphaFormat := afDefined; SetBitmapBits(bmp.Handle, img32.Width * img32.Height * 4, img32.PixelBase); //next copy from the...
-
Clipper library updated (Img32 dependency)
-
Great, thanks for the update. Also, I might be putting the merging of touching solution polygons on the priority list (to tackle before final release of Clipper2). That may delay things a bit but hopefully not too much.
-
Minor edit
-
Not sure I fully understand: the double version (PathD) does not need any typecasting as everything is double already. Yeah, sorry, I was referring (implicitly) to Area(Path64 path) since you'd also mentioned overflow, and I didn't think you'd be concerned about overflow when multiplying floating point values And very the reason the integer version of Area returns a double is to avoid overflow. The alternative (used in Clipper1) is to use custom 128bit integers, but they create an unnecessary performance...
-
Not sure I fully understand: the double version (PathD) does not need any typecasting as everything is double already. Yeah, sorry, I was referring (implicitly) to Area(Path64 path) since you'd also mentioned overflow, and I didn't think you'd be concerned about multiplying floating point values And very the reason the integer version of Area returns a double is to avoid overflow. The alternative (used in Clipper1) is to use custom 128bit integers, but they create an unnecessary performance burd...
-
Not sure I fully understand: the double version (PathD) does not need any typecasting as everything is double already. Yeah, sorry, I was referring (implicitly) to Area(Path64 path) since you'd also mentioned overflow, and I didn't think you'd be concerned about that with floating point coordinates. And very the reason the integer version of Area returns a double is to avoid overflow. The alternative (used in Clipper1) is to use custom 128bit integers, but they create an unnecessary performance ...
-
Not sure I fully understand: the double version (PathD) does not need any typecasting as everything is double already. Yeah, sorry, I was referring (implicitly) to Area(Path64 path). And very the reason this function returns a double is to avoid the risk of overflow. The alternative (used in Clipper1) is to use custom 128bit integers, but they create an unnecessary performance burden.
-
Just tried if ClipperLib2 can do it...no luck. Is this something you would expect Clipper2Lib to ultimately be able to do, Bummer! And YES!!! Though I'm not sure what you mean by glitches. If you're meaning that the solution is technically correct (as I expect) but there are polygons in the solution that touch each other and could be simplified, then this is something that's on the "road map" for future but not promised. If you are getting results from Clipper2 that aren't technically correct, I'd...
-
Hi again Terence. The area formula used in clipper continues to confuse me LOL, it confuses me too! 😕 All my development has been done using inverted Y-axis displays (0,0 at top left). This of course reverses winding orientation (clockwise vs counterclockwise ) and I recently I tried to fix this with a pre-compiler switch (that reverses orientation). Howver, in doing this I broke things and, rather than persisting, I reversed the changes. Thanks to your feedback here I'll make a more concerted effort...
-
Hi again Terence. The area formula used in clipper continues to confuse me LOL, it confuses me too! 😕 All my development has been done using inverted Y-axis displays (0,0 at top left). This of course reverses winding orientation (clockwise vs counterclockwise ) and I recently I tried to fix this with a pre-compiler switch (that reverses orientation). Howver, in doing this I broke things and, rather than persisting, I reversed the changes. Thanks to your feedback here I'll make a more concerted effort...
-
Hi Terence. Thank you for your feedback on this. It does need more attention, at least on my part. I do pretty much all my coding in Delphi, and this was an area in the C# code where I took what seemed a reasonable shortcut/compromise. However, I agree with you now that the IsNearZero function isn't ideal/satisfactory. However, in practise, this isn't a problem for the Clipper Library internally. In my Delphi code, the comparable PointD class doesn't have equality or inequality operators because...
-
Img32
-
Hi again Daniel. Firstly, I'm happy to hear zooming is working for you. 👍 Using ClearType inside TSvgReader isn't feasible. ClearType is only of (limited) value when drawing text over solid colors, typically a white background. In theory it can also be done over colored and even patterned backgrounds, but it's debatable if anyone would find the text any clearer. And I really can't envisage a way to do this in SVG in a time efficient manner, and one that would justify the considerable effort. ps:...
-
Hi again Daniel. Firstly, I'm happy to hear zooming is working for you. 👍 Using ClearType inside TSvgReader isn't feasible. ClearType is only of (limited) value when drawing text over solid colors, typically a white background. In theory it can also be done over colored and even patterned backgrounds, but it's debatable if anyone would find the text any clearer. And I really can't envisage a way to do this in SVG in a time efficient manner, and one that would justify the considerable effort.
-
Hi again Daniel. Firstly, I'm happy to hear zooming is working for you. 👍 Using ClearType inside TSvgReader isn't feasible. ClearType only works when drawing text over a solid color, typically a white background. And I really can't envisage a way to do this in SVG since there's no sensible (time efficient) way to determine text backgrounds.
-
Stretching the current rendered image while zooming (see svg application), while certainly faster is not sharp, Indeed. That's because the stretching is done by pixel interpolation (resampling) rather than by vector scaling and re-rendering (ie rasterizing). this process can benefit from a total reload of the vectorial information of a SVG (slower) Actually, it may be quite a bit quicker because raster scaling isn't very fast (unless using a very inferior resampler - eg nearest neighbor). And the...
-
HI Daniel. Thank you for your very encouraging feedback I was looking into the SVG application, which compiled just fine, but I didn't figure how to use the vectorial scaling advantage when the loaded image is a SVG in TImage32Panel. The idea is to scale the vector image before rendering it, and this is easily managed by setting the image's size before loading the image from file. This may seem strange since we're all so used to loading raster images using their fixed dimensions and then scaling...
-
HI Daniel. Thank you for your very encouraging feedback I was looking into the SVG application, which compiled just fine, but I didn't figure how to use the vectorial scaling advantage when the loaded image is a SVG in TImage32Panel. The idea is to scale the vector image before rendering it, and this is easily managed by setting the image's size before loading the image from file. This may seem strange since we're all so used to loading raster images using their fixed dimensions and then scaling...
-
HI Daniel. Thank you for your very encouraging feedback I was looking into the SVG application, which compiled just fine, but I didn't figure how to use the vectorial scaling advantage when the loaded image is a SVG in TImage32Panel. The idea is to scale the vector image before rendering it, and this is easily managed by setting the image's size before loading the image from file. This may seem strange since we're all so used to loading raster images using their fixed dimensions and then scaling...
-
Wrong output when using ctDifference
-
Img32.Vector
-
Clipper2 beta moved to GitHub
-
I'll email you the Delphi code.
-
The triangulation code mostly works, and works well. But it crashes when under significant load, so it's not yet fit for inclusion in the library.
-
I'm not committed to the idea, but I thought it would be a helpful differentiation of the two classes.
-
How about ... private static bool IsNearZero(double value) { return (Math.Abs(value) <= Double.Epsilon); } public static bool operator ==(PointD lhs, PointD rhs) { return IsNearZero(lhs.x - rhs.x) && IsNearZero(lhs.y - rhs.y); } public static bool operator !=(PointD lhs, PointD rhs) { return !IsNearZero(lhs.x - rhs.x) || !IsNearZero(lhs.y - rhs.y); } I think it's a lot cleaner, but will the compiler inline the IsNearZero function call?
-
👍
-
Do I Understand that for the XOR operation all edges are HOT Not necessarily. Yes, all edges will be HOT when using EvenOdd filling. But they won't be HOT when using NonZero filling and Abs(edge.WindCount) > 1;
-
Thanks. 👍
-
The triangulation code mostly works, and works well. But it crashes when undersignificant load, so it's not yet fit for inclusion in the library.
-
Thanks. Will update. But wondering if the following may be simpler... public static bool operator !=(PointD lhs, PointD rhs) { return !(lhs == rhs); }
-
Hi again Phil. The answer would've been more obvious if your keyhole_sizing variable had been 50000. Anyhow, EndType.Closed (which is about to be renamed EndType.Joined as it currently is in the Delphi code) corresponds to EndType.etClosedLine in Clipper1. This is very different to EndType.Polygon that corresponds to EndType.etClosedPolygon in Clipper1. You've most likely just been confused by another name change, but to clarify for others (in the absense of any Clipper2 documentation) ... offsetting...
-
Updated Clipper2 beta
-
Hi again Phil. The answer would've been more obvious if your keyhole_sizing variable had been 50000. Anyhow, EndType.Closed (which is about to be renamed EndType.Joined as it currently is in the Delphi code) corresponds to EndType.etClosedLine in Clipper1. This is very different to EndType.Polygon that corresponds to EndType.etClosedPolygon in Clipper1. You've most likely just been confused by another name change, but to clarify for others (in the absense of any Clipper2 documentation) ... offsetting...
-
Hi again Phil. The answer would've been more obvious if your keyhole_sizing variable had been 50000. Anyhow, EndType.Closed (which is about to be renamed EndType.Joined as it currently is in the Delphi code) corresponds to EndType.etClosedLine in Clipper1. This is very different to EndType.Polygon that corresponds to EndType.etClosedPolygon in Clipper1. You've most likely just been confused by another name change, but to clarify for others (in the absense of any Clipper2 documentation) ... offsetting...
-
Hi again Phil. The answer would've been more obvious if your keyhole_sizing variable had been 50000. Anyhow, EndType.Closed (which is about to be renamed EndType.Joined as it currently is in the Delphi code) corresponds to EndType.etClosedLine in Clipper1. This is very different to EndType.Polygon that corresponds to EndType.etClosedPolygon in Clipper1. You've most likely just been confused by another name change, but to clarify for others (in the absense of any Clipper2 documentation) ... offsetting...
-
Hi again Phil. The answer would've been more obvious if your keyhole_sizing variable had been 50000. Anyhow, EndType.Closed (which is about to be renamed EndType.Joined as it currently is in the Delphi code) corresponds to EndType.etClosedLine in Clipper1. This is very different to EndType.Polygon that corresponds to EndType.etClosedPolygon in Clipper1. You've most likely just been confused by another name change, but to clarify for others (in the absense of any Clipper2 documentation) ... offsetting...
-
Hi again Phil. The answer would've been more obvious if your keyhole_sizing variable had been 50000. Anyhow, EndType.Closed (which is about to be renamed EndType.Joined as it currently is in the Delphi code corresponds to EndType.etClosedLine in Clipper1) is very different to EndType.Polygon (that corresponds to EndType.etClosedPolygon in Clipper1). In a sense, offsetting polygons is unidimensional in that positive offsets extend away from every edge's left side, whereas offsetting open paths (polylines)...
-
SimplifyOption was really a Union (to tidy self-intersections) and then a colinear removal. Neither self-intersections or colinear spikes should be an issue in Clipper2. It's the joining of touching polygons in solutions that was unsatisfactory in Clipper1 and left out of Clipper2.
-
There is a ReversePaths function but I suspect it hasn't been exposed as public.
-
Naively, I thought this might be done by looking for angles ~180 degrees (where epsilon is the tolerance). I'm very open to colaboration and incorporating useful code. 😁
-
Is the order of argument change intended? Yes, it is 😜. Is it intentional to make the fill rule a required parameter Yes. This parameter should never have had a default value. (I also over complicated this in Clipper1 by having two filling rules, so users could specify different filling from Subject and Clip paths.) Nevertheless, the filling rule is crucial to clipping behavior and I'm not persuaded that most uses would default to even-odd filling. The filling rule really should be explicit. Anyhow,...
-
I'll put this on my growing todo list 😱.
-
I'll fix. Thanks again for all the feedback. 👍
-
and migrating this I now seem to have PathsD: That's temporary, I will definitely add in aPaths option too. There doesn't appear to be a helper in ClipperFunc to go from PathsD to Paths That too will be fixed soon. 😁
-
Nope, Clipper1 didn't do this well, and the code was complicated and messy, so it's been removed. There are currently no functions or methods to do this, at least until I can figure out how to do this better than it was done in Clipper1.
-
Yes, the GetBoundsmethod will return the bounds of all paths submitted to the Clipper object (by prior AddSubject and AddClip methods).
-
Yes, that Method will return the bounds of all paths submitted to the Clipper object (by prior AddSubject and AddClip methods).
-
👍. However, if there's a better was to do this (apart from urgently needed documentation that I'm now working on) I'm still very open to your suggestions. (And Phil, you're very welcome to email me with suggestions.)
-
I understand that this could cause confusion. However I've also removed the AddPaths method in favor of AddSubject and AddClip methods so my hope was, with very clear documentation, this wouldn't cause too much angst. Given that most users would clip closed paths, I thought the more logical parameter should be IsClosed, and the default. IOW, how this was managed in Clipper1 was counter-intuitive. But I'm open to persuasion 😜 and this could easily reverse this (before final release).
-
Hi Ignorant. Once again, it would be really helpful if you stopped quoting previous messages in you reply posts. People can already see previous messages so you're just adding a lot of noise with this quoting.
-
As you've noticed, yes this feature isn't currently supported. However, depending on the level of interest, I could be persuaded to reimplement the Z coordinate. (And you present a good case for that 👍.)
-
Hi Phil. Wow, lots of quesiion ... which is great feedback ... but now I have to try and answer them all 😱. As you've correctly noticed, there's no preserve colinear property. This is because Clipper2 no longer tries to merge colinear edges. In Clipper1, this feature was complicated and with messy code and provided a far from perfect solution. So, at least for the time being, I've removed this option.
-
Img32.Vector
-
Clipper2: Bugfix for open path clipping
-
Added credits WRT C# port
-
Readme for Clipper2 beta tests versions (Delphi & C#)
-
Clipper2 moved to trunk
-
-
Minor bugfix and refactoring
-
Delphi Clipper2 release candidate 1
-
Minor bugfix in Img32.Layers
-
Fixed compatibility issues with older versions of Delphi.
-
Hi John. The Delphi version of Clipper2 is now complete so I'm ready to focus on the C++ and C# translations. If could email me your C# version, or upload it somewhere, I'd be very happy to look at it. Nevertheless it won't be a quick fix because I've made quite a few changes recently to Clipper2. Also, FYI, I've attached a performance comparison between Clipper1 and Clipper2
-
Delphi Clipper2 release candidate 1
-
Fixed bug in Grow function introduced in a recent upload.
-
Delphi Clipper2 pre-release version.
1 >