forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

v8.5 Personal - 'Missing' TEX & SVG Routines ?
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
John-Silver



Joined: 30 Jul 2013
Posts: 1202
Location: Aerospace Valley

PostPosted: Fri Aug 16, 2019 12:56 am    Post subject: v8.5 Personal - 'Missing' TEX & SVG Routines ? Reply with quote

v8.5 Personal - 'Missing' TEX & SVG Routines ?


I've installed v8.5 Personal and am attempting to try out the new TEX equation and SVG facilities introduced into ftn95.

I'm failing at the start.

1. 'Missing' Routines ?

The compiler doesn't find any of the following routines at linking :-

Quote:
WARNING the following symbols are missing:

IMPORT_SILVERFROST_SVG
.
.
SAVE_TEX_SVG_CONVERSION
.
.
IMPORT_TEX_OBJECT


I'm obviously missing something obvious.

Is there maybe another specific *.INS file (apart from those in the windows.ins file) which needs to be INCLUDEd for these routines ?

After downloading I did notice that the size of the installer is much smaller than the v8.4 Personal installer ( 47 (111 installed) compared with 70 (140ish installed)
I don't know if that is related or not.

Even if it's not related, why is the installer so much smaller ?

2. Problems Running 'EditSVG'

a) I also note that 'svgedit' when called from the command line I get the error:
'svgedit' is not recognized as an internal or external command'
on trying to run it
It does exist in the ftn95 folder.

b) Running 'EditSVG' by double-clicking I then tried a simple:
File > Open TeX command via the menus
and I get the following error when trying to read in either of the example TeX files given in the documentation linked to above at the start of this post :-

Quote:
file not found at address 1c008629
Within file editsvg.exe
in load_svg(enumÄlogical) at address 4dc
in get_input_tex_file_callback(void) at address fb
Within file CLEARWIN64.DLL
In _set_mg_return_value at address 5CF2
In TranslateMessageEx at address 29D
Within file USER32.dll
In TranslateMessage at address 1E2

RAX = 0000000000000159 RBX = 000000000240ddb0 RCX = 000000001c042d40 RDX = 0000000000000003
RBP = 000000001c000000 RSI = 000000000000000e RDI = 000000000240ddb0 RSP = 000000000240dcf0
R8 = 000000000240ddb0 R9 = 000000001c042d40 R10 = 000000001c042d40 R11 = 000000001c042d40
R12 = 0000000000402e4d R13 = 0000000000402f11 R14 = 000000000240f110 R15 = 000000000240f100

1c008629) int 9


John S
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6034
Location: Salford, UK

PostPosted: Fri Aug 16, 2019 9:03 am    Post subject: Reply with quote

John-Silver

Thank you for your post.

1) The headers should have been added to clearwin.ins and the associated mod files. I have updated clearwin.ins and you can download the new version via the following link...

https://www.dropbox.com/s/puw7w3u2r5dkxek/clearwin.ins?dl=0

Please note that the Fortran routines end with @.

2) The name of the executable is EditSVG and not svgedit.

3) I think that you are expected to provide your own image files but I will make enquiries and get back to you if these should have been supplied.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1202
Location: Aerospace Valley

PostPosted: Fri Aug 16, 2019 10:39 am    Post subject: Reply with quote

Thanks Paul, however ...

Quote:
1) The headers should have been added to clearwin.ins and the associated mod files. I have updated clearwin.ins and you can download the new version via the following link...

After updating (substituting) the clearwin.ins supplied, It still doesn't work because you didn't supply the revised associated mod files you refer to.

Quote:

Please note that the Fortran routines end with @.

Yes I know, but the '@' doesn't appear in the error message.
In fact it has a '#' on the end in the error messages (I edited out along with the filename before posting to save space)

Quote:
2) The name of the executable is EditSVG and not svgedit.

Guilty ! Thank you for correcting my word dyslexia Smile

Quote:
3) I think that you are expected to provide your own image files but I will make enquiries and get back to you if these should have been supplied.

Not sure what you mean by this comment.
I assume it's in reply to my second problem.

With the File -> Open_TeX selection you just supply a *.TEX fle not an image file.

I then get a small dialogue (Green background) which pops up 'Wait for TEX File Conversion' and after a few seconds it just disappears and I'm left with a blank screen.

No message. No *.svg file created (in the directory where the prog ... ah, where are the generated SVG files stored when created ?

I ran twice, once double-clicking to launch the app, again from command line from a specific directory and can't see any created file.

P.S.
The first line of the 'error' message (which I ddn't post in my original post) is:
Quote:
Silverfrost 64-bit exception report on C:\Program Files (x86)\Silverfrost\FTN95\editsvg.exe Fri Aug 16 01:32:39 2019


It may not be related but I don't understand, why does it says 64bit exception when I'm running 32bit?

P.P.S.
you also missed (because I forgot to put it in bold, sorry) my:-
Quote:
Even if it's not related, why is the installer so much smaller ?

_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6034
Location: Salford, UK

PostPosted: Fri Aug 16, 2019 12:07 pm    Post subject: Reply with quote

John-Silver

If you are using INCLUDE and clearwin.ins then you don't need the associated mod files. Mod files are for USE statements.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1202
Location: Aerospace Valley

PostPosted: Sat Aug 17, 2019 1:48 am    Post subject: Reply with quote

Thanks again Paul, we're making progress, slowly.
I'd been just trying to re-link after updating the windows.ins file.
After re-compiling then linking, an SVG file with a formula is now created. Tick V.G. .
Here's the image created (it's the temporary file), you can see the large amount of white space around it as referred to in the documentation °°(I think this is due to the .EPS file preceding the SVG generation bing a full A4 page size (see message in screengrab below where the eps image size is quoted at around 20mm x 30mm -ish.)

To Note - the filename is: __SVGTEMP.svg (that's a double underscore at the beginning there)
As the program fails before reaching
CALL SAVE_TEX_SVG_CONVERSION@()
I still don't know yet what the filename of the saved file will be (it's not documented as far as I can see)

But ,,,,, there's still an error ....
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1202
Location: Aerospace Valley

PostPosted: Sat Aug 17, 2019 1:49 am    Post subject: Reply with quote

Anyway, so here's the very crude test program I've been trying to run ...
Quote:
! ftn95-ex-svg_tex_eqn_gen-1a-REPROD3.f95
!
!
INCLUDE <windows.ins>

INTEGER i,icolor,ans
DOUBLE PRECISION x1, x2, y1, y2, x(3), y(3)

DOUBLE PRECISION X_OFFSET, Y_OFFSET, SCALE, WIDTH,HEIGHT
DOUBLE PRECISION X_OFFSET2, Y_OFFSET2, SCALE2

X_OFFSET = 0.0d+00
Y_OFFSET = -100.0d+00
SCALE = 1.0d+00

CALL IMPORT_TEX_OBJECT@("ftn95-Tex_ex_1a-NormCumDistrEq.tex",X_OFFSET,Y_OFFSET, SCALE,WIDTH,HEIGHT)

PRINT*, 'SVG image WIDTH = ',WIDTH
PRINT*, 'SVG image HEIGHT = ',HEIGHT

WRITE (6,*) 'SVG image WIDTH = ',WIDTH
WRITE (6,*) 'SVG image HEIGHT = ',HEIGHT

CALL SAVE_TEX_SVG_CONVERSION@()

ans = open_svg@("sample2incleqn.svg",800,600)

i = winio@("%gr%lw",800,600,ictrl)


! At any point where you could call a graphics primitive, you may make a call of the following form:

X_OFFSET2 = 100.0d+00
Y_OFFSET2 = -200.0d+00
SCALE2 = 1.0d+00


CALL IMPORT_SILVERFROST_SVG@("__SVGTEMP.svg",X_OFFSET2,Y_OFFSET2, SCALE2)


ans = close_svg@(0)



END
Code:

_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1202
Location: Aerospace Valley

PostPosted: Sat Aug 17, 2019 1:54 am    Post subject: Reply with quote

the TEX input file: ftn95-Tex_ex_1a-NormCumDistrEq.tex"
contains ....
Code:
%
% Latex Code for Normal Cumulative distribution
% (from ftn95 documentation:  https://silverfrost.com/ftn95-help/clearwinp/gdialog/svg.aspx)
%
% ftn95-Tex_ex_1a-NormCumDistr.tex
%
      \documentclass[12pt]{article}
      \usepackage{amsmath,bm}
      \pagestyle{empty}
      \begin{document}
      \Large
      \[
         \frac{1}{\sigma \sqrt{2\pi}}
         \int\limits_{-\infty}^x
         \exp -\left\{
         \frac{1}{2} \left( \frac{t-\mu}{\sigma} \right)^2 \right\}\,dt
      \]
      \end{document}

_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1202
Location: Aerospace Valley

PostPosted: Sat Aug 17, 2019 1:54 am    Post subject: Reply with quote

And I get the following in the command window, and the dialog at point of failure.

The point of failure seems to be before the end of the statement:-
CALL IMPORT_TEX_OBJECT@("ftn95-Tex_ex_1a-NormCumDistrEq.tex",X_OFFSET,Y_OFFSET, SCALE,WIDTH,HEIGHT)
... since neither the PRINT* nor WRITE statements produce anything.
The full Error in the dialog box text form is as follows :-
Quote:
Runtime error from program:c:\0 - stuff store\000 - star stuff\forum - sample progs\0 - ftn95 example programs\svg\simple tex
Access Violation
The instruction at address 100e5bf8 attempted to read from location 00000080

100e5be6 __get_current_graphics_handle [+0012] 1010a370 __setup_offscreen_area [+000c] 1010a3ed process_svg_body(void) [+00b8] 1010bd15 __import_silverfrost_svg [+049c] 1010c4d7 __import_tex_object [+02a6] 00401000 MAIN# [+007d]
eax=00000003 ebx=00000000 ecx=00000000
edx=00000002 esi=0977082e edi=1021d842
ebp=0360c934 esp=0360c918 IOPL=3
ds=002b es=002b fs=0053
gs=002b cs=0023 ss=002b
flgs=00010206 [NC EP NZ SN DN NV]

100e5bf8 mov eax,[ebx+0x80]
100e5bfe jmp 100e5c03
100e5c03 lea esp,[ebp-0xc]


So, why is this failing ?
I must surely be something stupid (again).
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1202
Location: Aerospace Valley

PostPosted: Sat Aug 17, 2019 1:59 am    Post subject: Reply with quote

P.S. - don't forget the subsidiary problem reading a TEX file into EditSVG via the menu.
I assume the last info I posted has been passed to those concerned with that development.

There's also (from my previous feedback):
Quote:
It may not be related but I don't understand, why does it says 64bit exception when I'm running 32bit?


Quote:
P.P.S.
you also missed (because I forgot to put it in bold, sorry) my:-
Quote:
Even if it's not related, why is the installer so much smaller ?

_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6034
Location: Salford, UK

PostPosted: Mon Aug 19, 2019 7:09 am    Post subject: Reply with quote

John-Silver

The author of EditSVG has read your post and here is his response...

The normal procedure when loading a TeX object is to use IMPORT_TEX_OBJECT@ to load the image in the correct place on the screen. Internally this uses Latex to obtain an SVG file that contains the big border, but it then strips the border off as it loads it. All that should be automatic, but what I think John-S has done is saved the SVG file and then loaded that file with IMPORT_SILVERFROST_SVG@, which doesn't know it should remove the white border!

The call to IMPORT_TEX_OBJECT@ should be between the open_svg@ call and the close_svg@ call - because it writes its result onto the currently open graphics region.

There should be no call to IMPORT_SILVERFROST_SVG@ and __SVGTEMP.svg was a name used by the software and it probably got deleted before the system tried to open it.

The problem is that one of the commands in Latex - DVISVGM - does not accept paths like any sane program would, so everything has to happen in the user's directory!
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1202
Location: Aerospace Valley

PostPosted: Wed Aug 21, 2019 3:59 pm    Post subject: Reply with quote

REPLY TO Comments from David B (?) (via Paul) re- my TEX read error

Quote:
The normal procedure when loading a TeX object is to use IMPORT_TEX_OBJECT@ to load the image in the correct place on the screen. Internally this uses Latex to obtain an SVG file that contains the big border, but it then strips the border off as it loads it.

The point here is that the size of the created svg image is not known before the generation of the image ! Hence it's positioning 'programatically' is impossible at that stage.

Even after creating the image (in it’s own native graphics window) neither the size nor positioning of the TEX graphics is known !

The SVG graphics window size is user-specified.

Hence the impossibility to correctly position a graphic of a TEX file.
The ‘border cropped’ TEX graphic only thus needs to be saved and available separately

As does it’s cropped dimensions !

Since this operation is done during the import of the TEX graphic it should be a simple task to retain those parameters, and the cropped image, no ?
Quote:

All that should be automatic, but what I think John-S has done is saved the SVG file and then loaded that file with IMPORT_SILVERFROST_SVG@, which doesn't know it should remove the white border!


I don't think the problem §(the fatal error) is there because it hasn’t reached that statement before it fails !

As I posted previously:-
Quote:
The point of failure seems to be before the end of the statement:-
CALL IMPORT_TEX_OBJECT@(“ftn95-Tex_ex_1a-NormCumDistrEq.tex”,X_OFFSET,Y_OFFSET, SCALE,WIDTH,HEIGHT)
… since neither the PRINT* nor WRITE statements produce anything.


Quote:
The call to IMPORT_TEX_OBJECT@ should be between the open_svg@ call and the close_svg@ call – because it writes its result onto the currently open graphics region.


This is useful to know !

I’ve now changed it to be so.

Combined with putting the ‘SAVE_TEX_SVG_CONVERSION@’ statement BEFORE the ‘IMPORT_TEX_OBJCT@’ statement my program now runs without the fatal error previously seen.
Tick V.G.

It's to be noted that this is not entirely clear from the paragraph documenting it under section header ‘Reading SVG files previously output by ClearWin+ ‘ (see below).

The phrase ‘The image will be drawn into the currently open drawing surface’ could equally be ibterreted to include a %gr, for example.
Alhough I didn’t even put that !

Quote:
There should be no call to IMPORT_SILVERFROST_SVG@


This statement appears to be contrary to that currently written in the documentation:
Quote:
Reading SVG files previously output by ClearWin+
At any point where you could call a graphics primitive, you may make a call of the following form:
CALL IMPORT_SILVERFROST_SVG@("Something.svg",X_OFFSET,Y_OFFSET, SCALE)
X_OFFSET, Y_OFFSET and SCALE are REAL*8 quantities that specify the the position of the top left corner of the SVG image. The scale argument would typically be 1.0d0, but as explained above, an SVG file can be displayed at any resolution by adjusting this argument.
The image will be drawn into the currently open drawing surface.

I assume the ‘currently open drawing surface’ means an SVG drawing surface ? (or could it also be a %gr ?)


... to be continued in next comment...
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1202
Location: Aerospace Valley

PostPosted: Wed Aug 21, 2019 4:07 pm    Post subject: Reply with quote

... continued from previous comment...

The point is that eventually when I've unravelled the totality of what my error is I want to:-

a) create one single time a formula then use it via IMPORT_SILVERFROST_SVG@ and use it for several images (as suggested in the documentation).

b) this trial program is intended to first show the resulting generated image of the formula in a %gr window for checking and debugging purposes - eventually it will be done offscreen in a 'virtual window'

Quote:
and __SVGTEMP.svg was a name used by the software and it probably got deleted before the system tried to open it.

The file __SVGTEMP.svg didn't get deleted !

It was sitting there in the current working directory after the program failed.

Which is why I put it in the later IMPORT_SILVERFROST_SVG@ statement (which as I mention above hasn't yet been reached when the program fails.
I take the point you make that it will probably get deleted when the IMPORT_TEX_OBJEXCT@ statement finishes, is that right ? Or is it at the end of the program ?

I ask this because as you can see I've included the SAVE_TEX_SVG_CONVERSION@ command, and I still don't have an answer as to what name it uses for the saved SVG file (so I can subsequenty, eventually, read it in at that later point).

NOT BENE : After successfully running the program without runtime error, I can confirm that the SAVE_TEX_SVG_CONVERSION@ causes this file to be saved in the current directory with the same name (i.e. __SVGTEMP.svg).

Note also that that this __SVGTEMP.svg file is the image that I posted previously on this post

Double-clicking it opens it fine in my internet browser (Firefox) and the equation is visible.

It’s not just a ‘large border’, it appears to be positioned at some unknown (arbitrary) distance from the top of the screen, centred horizontally, on what appears to be an A4 sized page.

It DOES NOT however read correctly into the interactive EditSVG program, via the Open SVG menu commands of EditSVG (the standalone program), neither using the ‘with border’ nor ‘without border’ options.

The SVG drawing surface appears, but blank WITHOUT THE EQUATION.

But It DOES also read OK into some other SVG graphics programs, although sometimes it appears 'reversed' !
So maybe there's some inconsistency with the svg coding.

Remember also the previously reported error at the beginning of this post that the Open TEX file menu command doesn’t work with this file !

A couple of additional observations after having successfully running the modified program:-

a) the svg outut file from the IMPORT_TEX_OBJECT command does not show the equation when opened in Firefox.
b) It behaves in the same way as the SVGTEMP file with Editsvg (opens ‘blank’ via the menus + same via drag n drop)

Quote:
The problem is that one of the commands in Latex - DVISVGM - does not accept paths like any sane program would, so everything has to happen in the user's directory!

What do you mean by the 'user's directory' ?
I assume you mean the directory where the program is run (the current working directory) ?


... to be continued (again) in next comment...
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1202
Location: Aerospace Valley

PostPosted: Wed Aug 21, 2019 4:23 pm    Post subject: Reply with quote

... continued from previous comment...

In a PM from Silverfrost back in mid-June, when I made some initial enquiries regarding the TEX facility, was this phrase…
Quote:
We plot to a back screen and scan the pixels to find the smallest rectangle that contains the drawing. That sounds expensive, and I had worried that it might be, but on a modern PC (mine is a Core i5) the effect is near instantaneous. Thus if you want to do calculations on the exact size of the image, import to a VSCREEN, use the size information returned, and then copy the vscreen into the graphics screen.

I find no direct documentation of ***_VSCREEN (dbos commands) and it’s ‘new equivalents’ CREATE_GRAPHICS_REGION@ etc. are somewhat esoteric in their definition of application to finding the actual size of a cropped TEX graphic .
Additionally, the explanation given indicates that when cropped the cropped image is in .bmp format on the back screen, is that right ?
…. And when the ‘VSCREEN’ is copied to the graphics screen it will still be in .bmp format ?
Or is there a re-conversion back to an svg file first ? (which would seem logical if the aim is to keep the graphics screen re-sizeable …. Or maybe not because presumably the other graphics object commands are not in svg format)
e.g. if you took the example in the documentation and added an IMPORT_TEX_OBJECT command the resulting svg file would be ALL svg format ? .... or partly .bmp where the cropped TEX image is inserted ?
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1202
Location: Aerospace Valley

PostPosted: Wed Aug 21, 2019 4:25 pm    Post subject: Reply with quote

I'll wait for some feedback before posting my revised code which has now at least runs (albeit producing .svg files which are not entirely what I'm expecting as explained above)
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6034
Location: Salford, UK

PostPosted: Wed Aug 21, 2019 7:30 pm    Post subject: Reply with quote

John-Silver

This enquiry seems too long and complex to me. We have limited resources and many demands on our time.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+ All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group