Graphics font styles

In the following program, the text should be written initially in black, and then be overwritten in red (so that nothing of the black is seen. That happens if the two lines calling ITALIC_FONT@ are commented out.

      OPTIONS (INTL, DREAL)
      PROGRAM DEMO
      INCLUDE <WINDOWS.INS>
      INTEGER, EXTERNAL:: KB_DRAW
      IW = WINIO@ ('%ca[Demo]%gr%sc', 300, 100, KB_DRAW)
      END

      INTEGER FUNCTION KB_DRAW()
      INCLUDE <WINDOWS.INS>
      CHARACTER*(100) VALUE

      VALUE = 'Spencer, E (1967) A method of analysis'
      CALL DRAW_CHARACTERS@ (VALUE, 10, 10, RGB@(0,0,0))
      VALUE = 'of the stability of embankments'
      CALL DRAW_CHARACTERS@ (VALUE, 10, 25, RGB@(0,0,0))
      VALUE = 'assuming parallel inter-slice forces'
      CALL DRAW_CHARACTERS@ (VALUE, 10, 40, RGB@(0,0,0))
      VALUE = 'Geotechnique, 17, 11-26'
      CALL DRAW_CHARACTERS@ (VALUE, 10, 55, RGB@(0,0,0))

      VALUE = 'Spencer, E (1967) A method of analysis'
      CALL DRAW_CHARACTERS@ (VALUE, 10, 10, RGB@(255,0,0))
      VALUE = 'of the stability of embankments'
      CALL DRAW_CHARACTERS@ (VALUE, 10, 25, RGB@(255,0,0))
      VALUE = 'assuming parallel inter-slice forces'
      CALL DRAW_CHARACTERS@ (VALUE, 10, 40, RGB@(255,0,0))
      VALUE = 'Geotechnique, 17, 11-26'
      CALL ITALIC_FONT@ (1)
      CALL DRAW_CHARACTERS@ (VALUE, 10, 55, RGB@(255,0,0))
      CALL ITALIC_FONT@ (0)

      CALL PERFORM_GRAPHICS_UPDATE@ ()
      KB_DRAW = 2
      END

However, with the lines left in, the final line is displaced one line upwards. Something similar happens with BOLD_FONT@ and UNDERLINE_FONT@.

In my rather larger program (which does not overwrite) the effects are somewhat more far reaching, including wholesale displacement upwards of many text lines. The overwriting in the demo is merely to demonstrate what happens in a simple example.

Incidentally, the FTN95.CHM entry for ITALIC_FONT@ does not state what the values of the argument are.

I also noted that in FTN95.CHM the entry for HIGH_RES_CLOCK@ mentions calling DBOS, and elsewhere (I can't find it again) I came across a link that should invoke Internet Explorer - and doesn't on a modern PC.

FTN95 v8.50 used.

Eddie

(with apologies to Eric Spencer, but his paper is a time-waster!)

Thanks Eddie.

I have logged this for investigation.

Paul,

I hope that fixing this regression is high on your list of priorities, as it means that I can't do any development on a number of existing programs and that has wasted my self-isolation/house-arrest during a case of Covid!

Eddie

Eddie

I have now had an initial look at this.

I can't see any changes in ClearWin+ that would have an effect on this program.

The problem relates to the default font which is currently 'Courier New' and it is possible that this has inadvertently been changed. I will investigate further.

The immediate fix is to set the font via a call to SELECT_FONT@ and to use a font other than 'Courier New'.

Hi Paul,

Thanks for looking. It was slightly tongue in cheek, as I didn't really feel like doing anything at all while suffering ...

I only used the default setting, and if that is Courier New then that's what it is. At least the font is monospaced, so (in the real program) I was able to put the single Greek letter I wanted (gamma) into a bitmap and write that over the text string's 'g'. That turned out easier than changing fonts etc etc.

How I miss Escape code sequences to switch mid-string and back again.

Eddie

Eddie

The gamma character could be handled by using UTF8 characters strings. See ENABLE_UTF8@.

Hi Paul,

An interesting proposition, and one I would be keen to learn about - if only I knew what UTF-8 was! (Poor joke).

I rushed to FTN95.CHM, and there discovered:

Note: A suitable font (such as Courier New) must be used in order to display UTF-8 characters.

... which rather defeated the point, I felt, given what my original problem was!

Anyway, I had the booster jab this morning, with the promise that I would feel unwell for the next couple of days, so it probably doesn't need an urgent resolution ...

Eddie

Eddie

Here is your code adapted in order to start the text with a lower-case gamma character. The file must be saved using 'UTF-8 without signature' and Plato allows this under 'Advanced Save Options' in the File menu.

      WINAPP
      PROGRAM DEMO
      INCLUDE <CLEARWIN.INS>
      INTEGER, EXTERNAL:: KB_DRAW
      CALL ENABLE_UTF8@(1)
      IW = WINIO@('%ca[Demo]%gr%sc', 400, 50, KB_DRAW)
      END

      INTEGER FUNCTION KB_DRAW()
      INCLUDE <CLEARWIN.INS>
      CHARACTER*(100) VALUE
      CALL SELECT_FONT@('Loucida Console')
      CALL SCALE_FONT@(1.2D0)
      VALUE = '&#947; Spencer, E (1967) A method of analysis'
      CALL DRAW_CHARACTERS@ (VALUE, 10, 15, RGB@(0,0,0))
      KB_DRAW = 2
      END

I think that escape code sequences are still available in ClearWin (%cw) windows but I would have to check.

Hi Paul,

That's great. Thanks.

I really meant escape codes in text in a %gr graphics area. Sometimes I write things where everything happens in a single %gr client area. It's because I'm hopeless at doing anything in Excel apart from simple listing and tabulating and find writing a bit of Fortran a lot less frustrating.

I still think that the odd Greek character cut from a Word document using the Symbol font and edited in Paint to form a bitmap for pasting ends up being quicker (for me) as I'm an old dog. UTF-8 would definitely be a new trick*.

Eddie

*So is Plato. Saving the file in my favourite editor, and I just get a question mark, saving the file in Plato as UTF-8, and it won't compile. Is it spelt 'Loucida' anyway?

PS There's definitely something wrong. No matter where ITALIC_FONT@ appears in the code, the origin for line spacing is shifted upwards. Sure, other fonts are nice, but they are usually not monospaced, which makes tables go all over the place. I think that I'll put italics on my 'do not use' list.

Eddie

I have had another look at this but still I don't know where the problem lies. I also suspect that my initial comments above are without foundation.

Anyway, I suggest that you simply select the font that you want to use (it is possible this was always expected). In other words call SELECT_FONT@ before DRAW_CHARACTERS@.

The following code work correctly for me:

      WINAPP
      PROGRAM DEMO
      INCLUDE <WINDOWS.INS>
      INTEGER, EXTERNAL:: KB_DRAW
      IW = WINIO@ ('%ca[Demo]%gr%sc', 300, 100, KB_DRAW)
      END

      INTEGER FUNCTION KB_DRAW()
      INCLUDE <WINDOWS.INS>
      CHARACTER*(100) VALUE
      CALL SELECT_FONT@('Courier New')
      VALUE = 'Spencer, E (1967) A method of analysis'
      CALL DRAW_CHARACTERS@ (VALUE, 10, 10, RGB@(255,0,0))
      VALUE = 'of the stability of embankments'
      CALL DRAW_CHARACTERS@ (VALUE, 10, 25, RGB@(255,0,0))
      VALUE = 'assuming parallel inter-slice forces'
      CALL DRAW_CHARACTERS@ (VALUE, 10, 40, RGB@(255,0,0))
      VALUE = 'Geotechnique, 17, 11-26'
      CALL ITALIC_FONT@ (1)
      CALL DRAW_CHARACTERS@ (VALUE, 10, 55, RGB@(255,0,0))
      CALL ITALIC_FONT@ (0)
      KB_DRAW = 2
      END

Regarding UTF-8, you will need to use an editor that allows you to save using 'UTF-8 without signature'.

Hi Paul,

Many thanks for looking at it again.

I have absolutely no doubt that you are an infinitely better programmer than I am, but I'm equally certain that one day you will discover the underlying reason and it will give rise to a 'Why didn't I see that before!' moment. I have them on a fairly regular basis. It has happened twice with a particular paper,, where I have only recently become aware that the assumptions in an equation are wrong, and the dimensions on a Figure are incorrectly located.

It has taken over 50 years!

Eddie

PS I though I had it working in an old program, but it wasn't italics, it was rotation. Perhaps INTALIC_FONT@ hasn't worked for a long time.

Eddie

I will keep it on my list because there is something odd here that I don't understand.

In the rush I scanned over your note about infection with Covid. I do hope that it is not serious and that you soon recover.

Hi Paul,

Thank you for your concern. I did get over it - had it last month despite being double-jabbed - and had my booster yesterday. It was like a bad cold, allied with a lack of enthusiasm to do anything productive. Hence my poor taste joke about wasting time.

There is definitely something not quite right here. I have no doubt that you will fix it sometime.

Eddie

Eddie

I can now confirm that the original issue on this thread is not a regression. I get the same behaviour on an old machine dated c2014.

If the font is not selected via SelectFont@ then you will get the 'System' font and that will depend on the version of Windows and your personal settings.

I don't think that this is something that can be 'fixed' in ClearWin+ but I will check the documentation and make sure that a call to SelectFont@ is recommended before calling DrawCharacters@.

As an aside, the old machine boots up in about 10 minutes or so. I guess it was a case of switching it on before making breakfast. Then my mind goes back to earlier days... Now with SSD drives we have no excuse for day-dreaming.

Blimey, Paul!

I wouldn't count a machine dating back to 2014 as 'old', but there we are. I was already retired for 2 years!

Anyway, it's good to know that it isn't a regression.

For some reason I have believed that the coordinates given are for the top left corner of the text string - heaven only knows why except that it seems to work - but the minute I SELECT_FONT@, the location is definitely the bottom left of the character string, so relative to not using the SELECT_FONT@ option, the text moves upwards by the corresponding amount. It therefore appears to me that the lower left location (as stated in FTN95.CHM's instructions for SELECT_FONT@) is not the case if no font is selected when a DRAW_CHARACTERS@ call is made, but begins to apply when SELECT_FONT@ or any of the font styling options is invoked.

As I have perhaps said before I read the instructions avidly, and note that FTN95.CHM's entry for 'ClearWin+/Graphics/Drawing text' says nothing about how the coordinates given work to position the text, so perhaps that is where a note is needed anyway.

Eddie