Integrated Inconsistencies.
I will get it wrong. I will start off by saying that, not just because I am married and this sentiment has been conjugally programmed in me for years, but because doing things "my way" will not suit everybody. We approach life, programming, drawing from different perspectives, different analogies, and one method however disagreeable to one person, may be perfectly logical to another. Even our own actions and analysis show conflicts. Take a cup of tea. I drink from the top of the cup, but measure from the bottom. Take character position in programming code...we measure lines from the top, then character on that line. But when we write, we write one line at a time, populating columns in a line before going to the next line.
The same applies to drawing onto a screen. The reason I want to draw on a screen is because I want to be able to draw charts...following the example of Descartes, one plots a point on X,Y coordinates with the origin on the bottom left hand corner. x comes before y. The same screen is drawn from top to bottom, and the print coordinates are described as row, column. with the origin at top left. Then examine what happens if I were to draw an SVG graph according to the Perl Weekly Challenge 165 by Ryan Thompson. How many people realised that the SVG coordinate system the x,y coordinates are not the same as Cartesian coordinates? You did? Well done!...but I dare say plenty of people didn't.
I wrote Term::Graille, not because Term::Drawille was not good enough, but out of sheer indignation. You see, using Braille characters to draw "Pseudo pixel" graphics on the console would be simple but while I might desire a y-axis that increases as we go up as in charts, the dots in braille characters are confusingly numbered and bit 0 is the top of the character.
Drawing lines requires clever calculations. So I then took over Algorithm::Line::Bresenham, and found the original code appeared to take the y-coordinate before the x-coordinate...blasphemy, even though it made no difference to the actual results (it works both ways equally). You will (or perhaps will not) be pleased to know that x comes before y in the newer extended versions. I even inverted the textAt() character coordinate system in Graille; printing to canvas requires the coordinate system to have Cartesian origins, as text in charts often have to be placed next to the plot positions they target.
Graille Incorporates Turtle-like graphics and line drawing primitives, and in this case using Cartesian coordinates makes perfect sense. Mapping is simple and up and north are positive directions. It appears possible that keeping consistent axes should be acceptable for most needs.
Now that is fine if the data is sourced internally; often however, the data is not. Using external data relies on external paradigms, and one has to accommodate the logic of another representation. Images are read as raster from top down, y=0 is the top line. So plotting on Graille requires the image to be read in and then inverted to look right way up.
for (my $x =0;$x<$canvas->{width};$x++){ for (my $y=0;$y<$canvas->{height};$y++){ $canvas->set($x,$y) # inverting image as the pixels are read if $image->GetPixel("x"=>$x,"y"=>$canvas->{height}-$y); } }
Then there is other bitmap data, font data or sprite graphics again represented top down, left to right. Conversion into blittable blocks requires this consideration. It is at this point I wonder if it is me that is going mad and whether I should stop trying to conflict with established paradigms. Then I realise that in a heterogeneous world conflict is inevitable, diversity is desirable, and confusion a natural and consistent consequence.
I continue updating Term:: Graille, extending drawille, integrating Turtle Graphics (as in the original asciimoo's version, but being in Perl, considerably more elegantly), Coloured lines, Image importing, Animations, 8x8 bitmap fonts, Heterogenous canvas etc, adopting a mainly Cartesian Coordinates for as much as possible. Maybe you think I am doing this completely wrong, but hey, I knew that all along. Version 0.07 coming soon!
I also confused at coordinate start from different forward:)
your work is amazing, I do not think this before!
And you changed it, breaking everybody's code who was using it, without even a mention in the docs nor changelog (which doesn't even exist). There's a strong tradition in the Perl community to support backwards compatibility. You could have added new functions (e.g. linex, circlex) that use the new argument order, and you wouldn't be inconveniencing users.
(The first paragraph of my previous reply was supposed to blockquoted, but guess my html tags weren't applied)
They were, but you used
<quote>
(which isn’t a thing, and which the tag filter therefore doesn’t permit) rather than<blockquote>
. I’ve fixed that for you.I did change the code, so it looks better (i.e. x come before the y) , output is not changed, and it will work either way. The output points' x-y order will match the the points input, so old code do not need to be altered. Secondly I have checked whether any one else uses it: according to the original author whom I have been in contact with, it is esoteric enough that nobody else uses it. But I agree I should have mentioned it in the pod. will do so in the next iteration.