forums.silverfrost.com
Welcome to the Silverfrost forums

 v8.5 Personal - 'Missing' TEX & SVG Routines ? Goto page 1, 2  Next
Author Message
John-Silver

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

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

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 ... "
PaulLaidler
Site Admin

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

 Posted: Fri Aug 16, 2019 9:03 am    Post subject: 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.
John-Silver

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

Posted: Fri Aug 16, 2019 10:39 am    Post subject:

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

 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 ... "
PaulLaidler
Site Admin

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

 Posted: Fri Aug 16, 2019 12:07 pm    Post subject: 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.
John-Silver

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

 Posted: Sat Aug 17, 2019 1:48 am    Post subject: 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 ... "
John-Silver

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

Posted: Sat Aug 17, 2019 1:49 am    Post subject:

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 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 ... "
John-Silver

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

Posted: Sat Aug 17, 2019 1:54 am    Post subject:

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 ... "
John-Silver

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

Posted: Sat Aug 17, 2019 1:54 am    Post subject:

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 ... "
John-Silver

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

Posted: Sat Aug 17, 2019 1:59 am    Post subject:

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 ... "
PaulLaidler
Site Admin

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

 Posted: Mon Aug 19, 2019 7:09 am    Post subject: 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!
John-Silver

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

Posted: Wed Aug 21, 2019 3:59 pm    Post subject:

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 ... "
John-Silver

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

Posted: Wed Aug 21, 2019 4:07 pm    Post subject:

... 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 ... "
John-Silver

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

Posted: Wed Aug 21, 2019 4:23 pm    Post subject:

... 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 ... "
John-Silver

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

 Posted: Wed Aug 21, 2019 4:25 pm    Post subject: 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 ... "
PaulLaidler
Site Admin

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

 Posted: Wed Aug 21, 2019 7:30 pm    Post subject: John-Silver This enquiry seems too long and complex to me. We have limited resources and many demands on our time.
 Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First
 All times are GMT + 1 HourGoto page 1, 2  Next Page 1 of 2

 Jump to: Select a forum Admin----------------Announcements FTN95----------------GeneralKBaseSupportSuggestionsClearWin+Plato64-bit FTN77----------------Support
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