Templot5 - progress discussions

[Martin Wynne]

@nickom @NoIdea @Rusty @Alistair Ward @graeme @Steve_Cornford @James Walters @Phil G @Paul Boyd @Tim Adams


The project to replace Templot2 with open-source Templot5 (T5) is now under way on GitHub:

https://github.com/Martin-Wynne/Templot5

All contributions welcome. Not just code -- we need help with docs, tutorials, videos too.

After 45 years of Templot it's time for me to sign off as the sole villain of the piece. What can you help us to get wrong next?

Martin.

 

[Steve_Cornford]

Hi Martin,

I can confirm that the latest version of PDF export is working on my laptop, including adjusting page size for roll printing.

Just thought that I would report the following, but perhaps you already know:-

When outputting to PDF and selecting Control Template only, it actually outputs the control template plus the background Templates.

Control template radio button ticked.

Resultant PDF

two background templates and the control template.
Steve

 

[Martin Wynne]

When outputting to PDF and selecting Control Template only, it actually outputs the control template plus the background Templates.

@Steve_Cornford

Hi Steve,

That's intended behaviour -- it's been that way since the beginning of time. When printing the control template you get any nearby background templates which happen to be on the same page.

1. the usual case is that you switch on and print a single template -- in which case there won't be any background templates:

https://85a.uk/templot/companion/your_first_printed_template.php

2. if you have a complex track plan, copying a template to the control and then printing the control template is a way to highlight it from its surroundings on the construction template.

With the arrival of plug track and timbering bricks, perhaps it's time to re-think some of these ancient concepts.

cheers,

Martin.

 

[Martin Wynne]

@Steve_Cornford

p.s. Steve,

If you wanted to change it you could add another tick-box or menu option somewhere.

At line 2376 in pdf_laz_unit:

Now:

pdf_laz_bgnd(grid_left,grid_top); // now print any background templates.

Could be:

if (print_entire_pad_flag=True) or (include bgnd templates with control template option=True)
then pdf_laz_bgnd(grid_left,grid_top);

And same again in print_unit.pas

Over to you.

Martin.

 

[Martin Wynne]

@Steve_Cornford @Andrew Tween

Hi Steve,

Thanks for your latest pull request. Merged.

You are motoring now! Are you happy to carry on with the fonts and cosmetics while I get back to the plug track and chairs?

Also we have another fork today -- Andrew Tween. Welcome to Templot Club, Andrew.

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,
If you go on collecting forks at this rate, you will soon have a 4 piece dinner set

Yes I am happy to progress the fonts & cosmetics.

Yesterday after an , I had a go at adding chair outlines to pdf_laz_unit (rather than print_unit,so as not to waste paper testing)

well at least it has added a couple of line in lieu of an S1 outline.

I am trying to track down the problem with showmessage statements.

mark_code 203 gets the ptr_2nd values and works, but mark_code 494 ends up with ptr_2nd=nil

but at least it has kept my hands & mind busy as I delve into the code (which I cut & pasted from math_unit)

I set gauge to BH. no5 to get the print as large as possible for testing!

Is it ok to attach the pdf_laz_uit.pas on here (rather than github) if I get really stuck?



Steve

 

[Martin Wynne]

Is it ok to attach the pdf_laz_uit.pas on here (rather than github) if I get really stuck?

@Steve_Cornford

Sure. That's why we have the OT2024 option in addition to T5. Ideally use the ...code forum section rather than here, but I can easily tidy up occasionally.

Have a look in grid_unit to see how the chair detail is drawn on the screen. For the print and PDF output it is essentially the same, using a different canvas and different scaling, and different origin settings for each page.

You will need to decide what colours to use. For printing solid infills it needs to be a pale color for infill, otherwise it wastes ink and the paper may get too wet causing cockles. Probably only the chair outlines are needed. They will be needed after doing the timber infill, otherwise they won't be visible.

rather than print_unit,so as not to waste paper testing)

For testing the print_unit function without wasting paper and ink, change the printer to Microsoft Print To PDF.

cheers,

Martin.

 

[Phil G]

If you go on collecting forks at this rate, you will soon have a 4 piece dinner set

In that case, when I feel a bit better, brain matter wise, and ready to have a go at the programming (like Steve) I will go with baby steps and try to control fonts ECT. first. I will create a spork just so we get a set.
cheers
Phil,

 

[Steve_Cornford]

Hi Phil,
If you want some advice on setting up etc, just give us a shout.
Steve

 

[Steve_Cornford]

Open-source links:

https://sourceforge.net/projects/opentemplot/

https://github.com/Martin-Wynne/Templot5
_______________________________________________________________________________________

Hi Martin,

I have made some progress with fonts & cosmetics on this form.

However there is no rail_number_image contained in the Timage object ( I assume a Lazarus conversion failure).

I tried copying the .picture = lines etc from the Delphi source but that did not work.

As a test I used Form editor with Object inspect and managed to import your 8-sided chair image, and that worked.
Obviously its not the correct image.

Any chance you could make available the .png or suitable image file for the rail_number_image?

Templot2 screen print:-

Steve

 

[Martin Wynne]

@Steve_Cornford

Hi Steve,

Here is the image:

It is 312 x 180, to fit rail_numbers_image.Picture on heave_chairs_form.

However, you shouldn't need it and I'm a bit puzzled why the Picture bitmap data didn't make it from the Delphi DFM file to the Lazarus LFM file.

I have now added it back into the heave_chairs.lfm file. Also I have put a copy of the image at \TEMPLOT5_OUTPUT\internal\hlp\ so that it can be included in the help notes for that form when they eventually get written.

I have pushed these changes to GitHub, so I hope they won't conflict with what you are doing. It means you don't need to do anything, your copy of the LFM file should get updated when you do a future fetch (I think?).

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,
Just created a Pull Request for you.
This includes:-
I have normalised the columns of chair_frame, which meant heading column changes to chairs_unit, and heave_chairs.
Also corrected group box sizing etc
Font normalisation & group box sizing to shove_timber.


As far as the heave chairs form, where there are two memo panels in top right corner:-
In form editor if you have left panel set to bold and right panel with no emphasis the lines line up, but after building , when running the laft hand text pane shrinks in size , so the lines do not align!
All the parameters are identical apart from justification.

so for time being have set to no emphasis for both.
Steve

 

[Steve_Cornford]

Hi Martin,
I think the problem between the two memo panels dispaying lies with the fact that in the left hand (capital letters only) panel there are no characters with descendors, whereas in the right hand panel there are descendor characters.

The Lazarus built version seems to shrink the left hand panel if bold is switched on, but leaves it the same size as the left hand panel if no emphasis.


Steve

 

[Martin Wynne]

@Steve_Cornford

Hi Steve,

Something going awry here. If you set the font height the same the line heights should be the same.

Compare with Templot2 from Delphi:

But something is going wrong with the client sizes too.

I notice that your forms are coming in with DesignTimePPI set to 96, whereas PixelsPerInch is 120.

Everything in Templot has been designed at 120 ppi and on every form Scaled is set False. This is so that the program size slider can work as intended and the dpi-aware function can ensure that everything appears crisp on all systems.

Delphi5 doesn't have a DesignTimePPI setting, and it's not clear what it does in Lazarus, or why it should differ from the PixelsPerInch run-time setting.

p.s. both these forms are child forms, so they don't need a datestamp_label. Windows puts a wide border on child forms, so we can let the hide panel in the bottom right corner control the scaling. For a neater result with child forms, I set the form colour to match the border colour. If you temporarily change the form colour, you can see the client size and the border.

procedure Theave_chairs_form.FormCreate(Sender: TObject);

begin
pad_form.InsertControl(heave_chairs_form); // child form
ClientWidth:=1060;
ClientHeight:=644;
AutoScroll:=True;
end;

I will find where the client size is going wrong and forcing the scrollbars to appear.

cheers,

Martin.

 

[Martin Wynne]

p.s. Steve,

The bolding problem can be solved by changing WordWrap to False on the memos, and maybe widening it a fraction:

p.p.s. using double memos was just a quick solution. Better would be to use an HtmlView with the content in an HTML table. Some extra formatting and spacing would then be possible.

Martin.

 

[Steve_Cornford]

Hi Martin,
I think the lack of the DesignTimePPI statement in the heave_chairs form was caused by the form editor.

I have re-inserted the DesignTimePPI statement in the heave_chairs form.
I temporarily copied all the .lfm file to a separate folder, then performed a notepad++ file search on them to be sure no others were missing the statement.
All 60 files contained the DesignTimePPI = 120 statement.

In the Form designer I have widened the right hand memo pane to 200 and get:-

Having performed a build, running Templot5 gives:-

To me it looks as if the left hand pane with bold has shrunk relative to the left hand pane.

But when I inspect heave_chairs.lfm with notepad++, the DesignTime statement has disappeared again.


I notice you have shove_timber as WIP, so I will leave you in peace while I work out what is going on with form editor.
Steve

 

[Martin Wynne]

@Steve_Cornford

Hi Steve,

I'm a bit puzzled. This is your form running in Lazarus on my system:

Everything seems to be fine.

The only changes I have made since your pull request are:

datestamp_label deleted (it was never needed).

right-hand memo changed to WordWrap=False.

form Width and Height set to match the original Templot2 Client sizes (can be found in the form OnCreate event).

---

Do you have your computer screen set to 96 dpi? It's the Windows default, but for every computer I have ever owned the very first thing I change has been to set 120 dpi. The whole of Templot has been designed at 120 dpi from the beginning of time. If you are working on a screen set to 96 dpi this may explain why you are seeing unexpected results in the Lazarus form editor with the Templot forms?

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,

Do you have your computer screen set to 96 dpi?

My screen is a 96ppi screen. That is its physical characteristic having 1366 x 768 pixels.
With windoze scaling set at 100% that is what i get.
The choice I get for scaling is either 100% or 125%.

Call me old fashioned but setting the scaling to 125% does not change the physical PPI, unless you are in a Microsoft universe where they change the size of an inch.

With my screen set to 100% scaling if I make changes to a Tform using the Lazarus editor, it removes the DesignTimePPI statement from the .lpm file, without asking me I might add!

Before it does this you can see in the Object inspector window the settings DesignTimePPI = 120, and also PixelsPerInch = 96.

If I set my screen to 125% scaling then DesignTimePPI = 120 (and persists after I close the form editor), and PixelsPerInch = 120.

So this means that I need to use 125% scaling when I am in Lazarus on this patricular laptop to avoid the IDE (Does this stand for Idiot Design Environment?) deleting this line.

This laptop is running Windoze 10 64-bit, but according to Microsoft is not capable of being upgraded to Windoze 11, so at some stage I will need to replace it, and when I do I will make sure that i get one with a higher resolution PPI screen.

For now I will live with it.

Desktop looks like this.

Forum looks like this.

Steve

 

[Steve_Cornford]

Hi Martin,
Just to say I am not trying to upset you, just stating my observations.

If it is a requirement to keep the DesignTimePPI = 120 statements then we need to point this pitfall out to other potential contributors to this project.

I would hate for anything I or others to upset your very fine applecart
Steve

 

[Martin Wynne]

My screen is a 96ppi screen. That is its physical characteristic having 1366 x 768 pixels.

@Steve_Cornford

Hi Steve,

Some confusion here. The PPI / DPI setting is a conversion factor for displaying font sizes, it is not a fixed physical characteristic of the monitor screen, which is in cells per inch.

My monitor measures 23.4" inches across and the native resolution is 2560 x 1440.

This means the physical cells per inch is 2560/23.4 = 109.4 cells per inch. This can't be changed by software.

The Windows settings for font conversion are:

100% = 96 ppi

125% = 120 ppi

150% = 144 ppi

Most programs (but not Templot) set fonts in Point sizes. A Point (pt) is 1/72nd of an inch, from traditional letterpress printing.

The ppi setting is used to convert Points to dot sizes on the screen.

---

So if you set text at 8pt and use 96 ppi, on the screen it will be:

8 x 96 / 72 = 10.67 dots. You can have only whole dots, so this is rounded to 11 dots.

In Delphi/Lazarus that is called the Font.Height and is shown negative to differentiate it from the Font.Size in pts.

On my screen the physical size of 11 dots is 11 / 109.4 cells per inch = 0.1005" (= 2.55mm).

---

If you set text at 8pt and use 120 ppi, on the screen it will be:

8 x 120 / 72 = 13.33 dots, rounded to 13 dots.

On my screen the physical size of 13 dots is 13 / 109.4 cells per inch = 0.1188" (= 3.02mm).

---

I have always used 120 ppi for everything -- and what Microsoft thinks about it doesn't cross my mind.

The default font height on most Templot forms is -13 dots, which means a button needs to be 20 dots height minimum to look right, and preferably 22 or 24 dots if there is room for it. Windows would mess with this on some screens and make it fuzzy. To prevent this we have Scaled=False on all forms, Scaled=False on the Application, and the program Manifest set to DPI-Aware=True. The actual on-screen sizes at run time are then controlled by the program size slider, and everything is kept crisp on all screens.

cheers,

Martin.

 

[Steve_Cornford]

So does this mean I need to set my screen scale to 125% in order to have an effective PPI of 120 when using Lazarus IDE to avoid the Form Designer from deleting the DesignTimePPI = 120 line?

In other words any contributor to the project should check that in Form designer the PixelsPerInch value (which i believe is garnered by Lazarus from windows) displayed by the Object inspect appears as 120?

Just want to be sure that others don't fall into the same trap as me.

Steve

 

[Martin Wynne]

Just to say I am not trying to upset you, just stating my observations.

@Steve_Cornford

Hi Steve,

I'm not upset!

I'm also not Microsoft or Apple, so I wouldn't dream of trying to tell anyone what they should or shouldn't do with their own computer.

Just want to be sure that others don't fall into the same trap as me.

I don't think you are in a trap. But I don't know what the Lazarus DesignTimePPI setting is intended for. There is no such setting in Delphi5. If it means that Lazarus uses a different PPI setting when designing a form from the PPI when the program is running, that is surely a recipe for confusion?

I suspect that somewhere here is the explanation for the Lazarus form.font bug, where the size increases every time you save and reload the LFM file. If you do that enough times the font size can reach 4 figures! Perhaps on a system set to 96dpi it doesn't?

For T5 contributors, presumably they will need to set DesignTimePPI to 120 every time they open an LFM file (assuming they are using Lazarus). But only if working on forms design -- it doesn't make any difference when working on functional code.

Presumably if the system is set to 120ppi, the DesignTimePPi comes up at 120 anyway (which is what seems to be the case on my system).

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,
The plot thickens...

If I have my screen scaling to to 100%, then when I use Form editor to make a change, it deletes the DesignTimePPI = 120 line from the .lfm, but leaves the .font of the form as it was upon entry.

If I have the screen scaling set to 125%, then when I use Form editor to make a change, it leaves the DesignTimePPI = 120 line in the .lfm file, but increases the .font size by 25% rounded.
Eg starting with -13 it changes it to -16.
Starting with -25 it changes it to -31.

Presumably that is the Lazarus bug you are referring to?

Steve

 

[Martin Wynne]

Presumably that is the Lazarus bug you are referring to?

@Steve_Cornford

Hi Steve,

Yes. That's why we have been removing the ParentFont=True setting on the child controls.

cheers,

Martin.

 

[Martin Wynne]

@Steve_Cornford

heave_chairs.pas
shove_timber.lfm
shove_timber.pas
chair_frame_unit.lfm
chairs_unit.lfm
heave_chairs.lfm
jigs_unit.lfm
jigs_unit.pas
dxf_unit.pas
dxf_unit.lfm

 

[Steve_Cornford]

Inspired by a walk in the sun?

 

[Martin Wynne]

Inspired by a walk in the sun?

Not really.

Just got to do something about the buttons -- I must have explained half a dozen times about "modify group to match".

It's time to move on from "it's experimental, there will be a temporary button somewhere" to "there's a big button right under your nose".

Otherwise the repeated explanations are driving me nuts. There's a whole essay to be written on resin exposure times, and Graham is still waiting for a page of Paddington scans and details of how to customize GWR crossings. Alistair has come back and wants to discuss the program structure.

I just feel that I never will be able to get back to plug track coding. It's all getting too much.

Martin.

 

[Martin Wynne]

.
Changes completed. 6 file changes uploaded to GitHub.

see:

https://85a.uk/templot/club/index.php?posts/12226

Martin.

 

[Steve_Cornford]

Hi Martin,
The rounded corners on some of the DXF export buttons look good in your example on the printer topic.

I have synced & updated my branch(fork). Then retreived chanegs to my local github.
Having copied them to my local Lazarus IDE folder & performed a build.

When I run Templot5 I dont get the rounded button corners. Is this a Windoze effect?

Steve

 

[Martin Wynne]

When I run Templot5 I dont get the rounded button corners. Is this a Windoze effect?

@Steve_Cornford

Hi Steve,

Windows10 = square corners

Windows11 = rounded corners

There are no settings in Templot to control this. Experienced Windows programmers may be able to change it via the program manifest, or via TControlCanvas on each button, but that's not me.

The coloured buttons with square corners in Templot are home-made buttons using TPanel. This way you can have coloured backgrounds and coloured text, and control what happens when the mouse moves over them (if anything). But it's more work than just using a TButton.

As a TPanel you could put anything else on it -- images, icons, arrows, etc., and they could change as the mouse moves over them.

In Delphi/Lazarus there is also the option of using a TBitBtn or a TSpeedButton which can have coloured text, but not a coloured background unless you create a bitmap glyph to use on them. All a lot more work. TSpeedButton can be set to latch down, as you can see on the pad toolbars (e.g. draw zoom rectangle).

You can have coloured buttons with rounded corners in HTML (web sites), and adjust the corner radius, but we would need to delve into the Firefox code to find how it's done. It won't be in Pascal when we find it.

cheers,

Martin.

 

[Steve_Cornford]

Unfortunately my laptop is not Windows 11 compliant, so for now will have to stick with Winows 10 & square corners

 

[Martin Wynne]

p.s. Steve,

Note that the new buttons are no help if you want to mix chairs and loose jaws on the same raft. For that use the modify group to match button.

 

[Steve_Cornford]

Hi Martin,

I have fixed the broken group title, and added a blue group title to export tab & to rails tab, using your suggestion of a TLabel to overlay the group box line.
Pull Request created.
Steve

 

[Martin Wynne]

@Steve_Cornford

Hi Steve,

PR received, merged and fetched. Looks good. Thanks.

In the long term I think we should replace all the TGroupBoxes with TPanels. Many of them need a clear border, and the border on the Lazarus groupboxes is very faint (and invisible on some colours). Without the Caption working properly there is no reason to use them, TPanels would make more sense. Compare with Templot2.

No doubt we also need a style advisor to create a consistent colour scheme across them, instead of the first colour which came into my head.

Lots of stuff to come back to when we have got a first version of Templot5 released.

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,

As an experiment....
I changed the quick_groupbox to a Tpanel using Notepad++ on dxf_unit.lfm & dfx_unit.pas.

I then used the form editor to add +10 to the Top of all the objects in the Tpanel and then amended the Top of the Label81 from -20 to -2 so that it actually appears within the Tpanel.

This gave this:_

Perhaps we should defer too much work on the cosmetics and just concentrate on getting the Templot5 version to an acceptable state for you?

What would you like me to concentrate on next?

Adding the fontsize and ParentFont = False to all objects contained with a form perhaps?

Just happy to do any housekeeping jobs like this so that we can get you back to the coding bit you enjoy (8 sided chairs?)

Steve

 

[Steve_Cornford]

For completeness as well as changing it to a Tpanel I have also renamed quick_groupbox as quick_panel.

Then making sure I was in 120dpi mode (125% scaled), and that the .lfm contained the DesignTimePPI = 120 line, performed a rebuild.

Steve

 

[Martin Wynne]

What would you like me to concentrate on next?

Adding the fontsize and ParentFont = False to all objects contained with a form perhaps?

Just happy to do any housekeeping jobs like this so that we can get you back to the coding bit you enjoy (8 sided chairs?)

@Steve_Cornford

Hi Steve,

I'm not here to issue instructions! What would you like to do?

We have had a request today for the chair types to be shown on the templates. As a starting point that might be easier on the control template on the screen where we already have the chair outlines. A screenshot could be printed out if wanted on paper (set the pad colour scheme to white).

Another job waiting is to get map_loader_unit.pas working for fetching historic map tiles from the NLS web site. Quite a few users make use of that. It was working in Lazarus in the 2018 code, so it should be possible to get it working again. The internet connection uses an open-source package called Synapse. Attached below is the zip for it. The first task is the folder \synapse_units\ needs to be copied and pasted into your working Lazarus and Git folders (the whole folder).

That folder contains the entire Synapse package. We likely don't need all the files and in due course some of them might be deleted.

All the relevant lines have been commented out OT2024 in map_loader_unit.pas so the first task is to uncomment them back in, and then see what Lazarus makes of it. The code for creating new background picture shapes might fail on the metafiles -- see in bgnd_unit.pas for the current temporary kludge around that.

The form map_loader_unit.lfm needs attention too.

It's possible Synapse has been updated since 2018, so having got the existing code working we might look at that.

Thanks for updating the group boxes on dxf_unit.lfm

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,
I will have a go at anything if it helps!
There is no try, there is only do!

I could not help myself compare the quick_panel with the Tpanel on the Export tab, and wondered if i would be better if they had the same border....

Where a group box has the same colour as the container it is sitting in the group box border looks ok.
For instance the 3-D file type: group box within the export format : group box.

...... waiting for a style advisor to step forward .....

I will have a look at chair types, I am scheduled to have a boiled for breakfast tomorrow, lets hope it gives me a moment!

Steve

 

[Martin Wynne]

.
did no-one spot the typo?

Presumably I have to upload this one small fix to GitHub straightaway? (now done).

Otherwise others may upload a version of dxf_unit without it and overwrite my local change?

Martin.

 

[Steve_Cornford]

Hi Martin,
Who else have you got uploading to github?

ps I have made some progress on chair labels

Well at least I have got a showmessage working that displays the correct name for each chair as it is being processed.
On this control template I have to press ok 24 times, but each one is giving correct chair name.

At the moment it only displays these if you switch rails off, the idea being that without the rails I will attempt to pt a chair label ontop of the chair.

Just got to understand your code for the timber numbering. eg draw a rectangle, fill it with text.

I am just taking it in easy steps so far.

This is in math_unit.pas of course.
Steve