q = SetConsoleTextAttribute(hConsole, int(FOREGROUND_RED .or. & FOREGROUND_INTENSITY .or. & BACKGROUND_BLUE .and. & BACKGROUND_RED, WORD))
I was not paying attention and I was looking to get a black background using the kernel32 function and I changed an .or. to an .and. without reading the instructions properly and the black background showed up, any ideas why this worked, should it have not been an error?
It would have been an error if you asked for standards checking. Please use IAND/IOR instead of .AND. and .OR. for "adding" bit mask integers. You can also use IANY to bitwise-OR more than two values.
What happened was that BACKGROUND_BLUE and BACKGROUND_RED got ANDed together, resulting in zero. This was ORed to FOREGROUND_RED (4) and FOREGROUND_INTENSITY (8) resulting in 12. Therefore, you set the foreground only and left the background as black.
If I do a search on BACKGROUND_BLUE and the others, I find nothing. Where do you find these values, my background is pure mathematics so the idea of 4 .or. 12 is not one I am used to, the idea of doing .and. on binary numbers makes sense. 011 .and. 100 is 111 so 3 .and. 4 is 8. In decimal it does not make sense. If I have had to do this sort of stuff I usually just do a set of if statements so the code may be long but it makes sense.
The problem arises from drawing bitmaps in Fortran. It is not difficult, but is tedious, we lack the large library of the .NET languages. I know I can use DISLIN, but the people who get the drawings say, we like the .NET ones, more professional.
It is easy to draw in DXF, but then one has to have AutoCAD and then plot the results, so a direct draw to bmp is quick and simple, but the subroutines ALL need to be written.
Provides some C code, I can get it to work, and I color coded the six pixels as they are small on a decent bmp, but the bitwise stuff has me stumped, plus it is really simpler to draw the 64 instead of saying only 26 count. Plus zserge makes each block 8 pixels, but that is trivial
I work through the 64 bit groupings logically like this -- compared to ++ this in a module so the constants are defined once as mecej4 taught me in Magni.
c.fillRect((i * 6 + (b & 1)) * px, (j * 6 + (b >> 1)) * px, px, px);
subroutine bits(rgb) implicit none integer i,j,b, n, px, k, l character*1 rgb(3,ihpixf,jvpixf) ! RGB pixel data array integer m(6) c All possible combinations for a 2x3 bitmap font const c = document.querySelector('canvas').getContext('2d'); px = 8 b = 0 do 140 i = 1,6 m(i) = 1 140 end do do 130 k = 1,1 select case (k) case (1) write(*,*)k case (2) write(*,*)k m(6) = 1 case (3) write(*,*)k m(6) = 0 m(5) = 1 case (4) write(*,*)k m(6) = 1 m(5) = 1 case (5) write(*,*)k m(6) = 0 m(5) = 0 m(4) = 1 case (6) write(*,*)k m(6) = 1 m(5) = 0 m(4) = 1 case (7) write(*,*)k m(6) = 0 m(5) = 1 m(4) = 1 case (8) write(*,*)k m(6) = 1 m(5) = 1 m(4) = 1 end select b = 1 do 100 i = 1,2 do 110 j = 1,3 if(m(b) .eq. 1) then if(j .eq. 1) then if(i .eq. 1) then call box(rgb,5*k+100+2*i,100+2*j,5*k+101+2*i,101+2*j,250,0,0) else call box(rgb,5*k+100+2*i,100+2*j,5*k+101+2*i,101+2*j,250,250,0) endif else if(j .eq. 2) then if(i .eq. 1) then call box(rgb,5*k+100+2*i,100+2*j,5*k+101+2*i,101+2*j,0,250,0) else call box(rgb,5*k+100+2*i,100+2*j,5*k+101+2*i,101+2*j,0,250,250) endif else if(j .eq. 3) then if(i .eq. 1) then call box(rgb,5*k+100+2*i,100+2*j,5*k+101+2*i,101+2*j,0,0,250) else call box(rgb,5*k+100+2*i,100+2*j,5*k+101+2*i,101+2*j,250,0,250) endif endif endif b = b+ 1 110 end do 100 end do b = b + 5 130 end do C // c.fillStyle = (n & (1 << b)) ? '#000' : '#fff';C C c.fillRect((i * 6 + (b & 1)) * px, (j * 6 + (b >> 1)) * px, px, px); return end
In the end taking a TTF and converting it to a bit map, appears to show that the TTF is just a set of simple line and shading representations, which is why it scales so well compared to hard coding bitmaps, that will not scale due to the length to width problems of the lines.
The easiest would be to write a TTF reader in Fortran and then a bitmap converter.
But most people only use one font, maybe 2. On my computer there are 7800 font files, most duplicates spread across every application and take up a 0.7GB, that is 35 times bigger than my first HD.
Better to write a line drawer and code each letter as lines and then they would scale.
These are defined in module IFWINTY. You will find IFWINTY.f90 in the compiler installation Include folder.
integer, parameter :: FOREGROUND_BLUE = #0001 integer, parameter :: FOREGROUND_GREEN = #0002 integer, parameter :: FOREGROUND_RED = #0004 integer, parameter :: FOREGROUND_INTENSITY = #0008 integer, parameter :: BACKGROUND_BLUE = #0010 integer, parameter :: BACKGROUND_GREEN = #0020 integer, parameter :: BACKGROUND_RED = #0040 integer, parameter :: BACKGROUND_INTENSITY = #0080
Why do you want to write bitmaps? How are the bitmaps used? If you want the graphical output to be scalable then you do not want a bitmap you want some form of metafile.
You are correct, I made a mistake with the and of a 0 and 1 it should be 0 - thank you
Thank you for the location of the parameters
The issues is getting a simple graphics package in Fortran. PLPLOT has errors in loading into Windows 10 with cmake, it tells you two files are missing plplot_version and plplot -- so that is a scrub.
A metafile would be nice, but all I need are simple files that will fit into a word doc or ppt.
It is terribly easy in C# and terribly complicated in Fortran.
I only need two text sizes on a simple font, so that is easier to write yourself.
So I got the C code working in Fortran, but I do all 64 instead of 26.
Thinking about what @mecej4 said, if I make these into a block of 4 groups, then I have 64 ^4 combinations which I could use as words, which if I took the OED, I could map the million words to a simple set of the 16 million available words and then I do not need spaces etc, we have a code. Fortran has the speed to do this.
We could duplicate the dictionary and never have to use a symbol twice, so hard to decode.
Some one will have thought of that.