Re: [Kicad-developers] i18n little problem

[Nick Østergaard]

2016-04-19 7:54 GMT+02:00 Marco Ciampa :
>> 2016-04-18 21:43 GMT+02:00 Marco Ciampa :
>> > I just a little problem I discovered.
>> >
>> > Under Linux, if you manage to change the language using the menu, some
>> > wxwindows related features (name on the buttons "cancel" and "Ok" on the
>> > 3D path settings for example) are determined from the "locale" language
>> > environment (that you can change from the command line with: "export
>> > LANGUAGE it_IT.UFT-8; kicad") only, independently of the kicad language
>> > setting.
>> >
>> On Tue, Apr 19, 2016 at 01:26:02AM +0200, Nick Østergaard wrote:
>> It is a little unclear what exactly you select in the language. But
>> this is expected when you click the default and not english or any
>> other language.
>
> Sorry for being unclear. I'll give you an example.
> My Locale settings is Italian (of course ... :-).
> In these days I am producing some screenshots in english so I switched to 
> English in the menu.
> If I open the footprint editor->path configuration I see as buttos: "Aiuto" 
> "Annulla" "Ok".
> I think this is wrong.

Are you sure that you didn't select the "default" language instead of "English"?

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] i18n little problem

[Marco Ciampa]

> 2016-04-18 21:43 GMT+02:00 Marco Ciampa :
> > I just a little problem I discovered.
> >
> > Under Linux, if you manage to change the language using the menu, some
> > wxwindows related features (name on the buttons "cancel" and "Ok" on the
> > 3D path settings for example) are determined from the "locale" language
> > environment (that you can change from the command line with: "export
> > LANGUAGE it_IT.UFT-8; kicad") only, independently of the kicad language
> > setting.
> >
> On Tue, Apr 19, 2016 at 01:26:02AM +0200, Nick Østergaard wrote:
> It is a little unclear what exactly you select in the language. But
> this is expected when you click the default and not english or any
> other language.

Sorry for being unclear. I'll give you an example.
My Locale settings is Italian (of course ... :-).
In these days I am producing some screenshots in english so I switched to 
English in the menu.
If I open the footprint editor->path configuration I see as buttos: "Aiuto" 
"Annulla" "Ok".
I think this is wrong.

--


Marco Ciampa

I know a joke about UDP, but you might not get it.



 GNU/Linux User #78271
 FSFE fellow #364




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [Branch ~kicad-product-committers/kicad/product] Rev 6698: Pcbnew: remove dead macro code.

[AndreyAF]

Wayne!

Remove macros code?
Why and what for?
I actively use this unique feathure.



revno: 6698
committer: Wayne Stambaugh 
branch nick: kicad
timestamp: Mon 2016-04-18 11:03:59 -0400
message:
   Pcbnew: remove dead macro code.
removed:
   bitmaps_png/cpp_26/macros_record.cpp
   bitmaps_png/sources/macros_record.svg
   include/class_macros_record.h
modified:
   bitmaps_png/CMakeLists.txt
   common/wildcards_and_files_ext.cpp
   include/bitmaps.h
   include/id.h
   include/wxPcbStruct.h
   pcbnew/hotkeys.cpp
   pcbnew/hotkeys.h
   pcbnew/hotkeys_board_editor.cpp
   pcbnew/menubar_pcbframe.cpp
   pcbnew/pcbframe.cpp
   pcbnew/pcbnew_config.cpp





--

Andrey Fedorushkov

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] i18n little problem

[Nick Østergaard]

It is a little unclear what exactly you select in the language. But
this is expected when you click the default and not english or any
other language.

2016-04-18 21:43 GMT+02:00 Marco Ciampa :
> I just a little problem I discovered.
>
> Under Linux, if you manage to change the language using the menu, some
> wxwindows related features (name on the buttons "cancel" and "Ok" on the
> 3D path settings for example) are determined from the "locale" language
> environment (that you can change from the command line with: "export
> LANGUAGE it_IT.UFT-8; kicad") only, independently of the kicad language
> setting.
>
> TIA
>
> --
>
>
> Marco Ciampa
>
> I know a joke about UDP, but you might not get it.
>
> 
>
>  GNU/Linux User #78271
>  FSFE fellow #364
>
> 
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] i18n little problem

[Marco Ciampa]

I just a little problem I discovered.

Under Linux, if you manage to change the language using the menu, some
wxwindows related features (name on the buttons "cancel" and "Ok" on the
3D path settings for example) are determined from the "locale" language
environment (that you can change from the command line with: "export
LANGUAGE it_IT.UFT-8; kicad") only, independently of the kicad language
setting.

TIA

--


Marco Ciampa

I know a joke about UDP, but you might not get it.



 GNU/Linux User #78271
 FSFE fellow #364




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Typos patch

[Martin d'Allens]

Hi all,
This patch fixes some simple typos.

https://github.com/KiCad/kicad-source-mirror/compare/master...Caerbannog:master.patch

Martin
From 6927d8781845bff2e95569e2205ce937c39aff96 Mon Sep 17 00:00:00 2001
From: Martin d'Allens 
Date: Mon, 18 Apr 2016 20:34:43 +0200
Subject: [PATCH] Fix some typos in the UI

---
 kicad/dialogs/dialog_template_selector.fbp  | 2 +-
 kicad/dialogs/dialog_template_selector_base.cpp | 2 +-
 pcbnew/exporters/gen_modules_placefile.cpp  | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/kicad/dialogs/dialog_template_selector.fbp b/kicad/dialogs/dialog_template_selector.fbp
index 4ceefd3..687a923 100644
--- a/kicad/dialogs/dialog_template_selector.fbp
+++ b/kicad/dialogs/dialog_template_selector.fbp
@@ -293,7 +293,7 @@
 0
 0
 wxID_ANY
-Templates path
+Template path
 
 0
 
diff --git a/kicad/dialogs/dialog_template_selector_base.cpp b/kicad/dialogs/dialog_template_selector_base.cpp
index 487e0d3..7328f89 100644
--- a/kicad/dialogs/dialog_template_selector_base.cpp
+++ b/kicad/dialogs/dialog_template_selector_base.cpp
@@ -23,7 +23,7 @@ DIALOG_TEMPLATE_SELECTOR_BASE::DIALOG_TEMPLATE_SELECTOR_BASE( wxWindow* parent,
 	m_htmlWin = new wxHtmlWindow( this, wxID_ANY, wxDefaultPosition, wxSize( -1,-1 ), wxHW_SCROLLBAR_AUTO );
 	bmainSizer->Add( m_htmlWin, 1, wxALL|wxEXPAND, 3 );
 	
-	m_staticTextTpath = new wxStaticText( this, wxID_ANY, _("Templates path"), wxDefaultPosition, wxDefaultSize, 0 );
+	m_staticTextTpath = new wxStaticText( this, wxID_ANY, _("Template path"), wxDefaultPosition, wxDefaultSize, 0 );
 	m_staticTextTpath->Wrap( -1 );
 	bmainSizer->Add( m_staticTextTpath, 0, wxTOP|wxRIGHT|wxLEFT, 5 );
 	
diff --git a/pcbnew/exporters/gen_modules_placefile.cpp b/pcbnew/exporters/gen_modules_placefile.cpp
index e6f3aa5..202ddb1 100644
--- a/pcbnew/exporters/gen_modules_placefile.cpp
+++ b/pcbnew/exporters/gen_modules_placefile.cpp
@@ -288,7 +288,7 @@ bool DIALOG_GEN_MODULE_POSITION::CreateFiles()
 
 if( singleFile  )
 {
-m_reporter->Report( _( "Componment Placement File generation OK." ), REPORTER::RPT_ACTION );
+m_reporter->Report( _( "Component Placement File generation OK." ), REPORTER::RPT_ACTION );
 return true;
 }
 
@@ -329,7 +329,7 @@ bool DIALOG_GEN_MODULE_POSITION::CreateFiles()
 m_reporter->Report( msg, REPORTER::RPT_INFO );
 }
 
-m_reporter->Report( _( "Componment Placement File generation OK." ), REPORTER::RPT_ACTION );
+m_reporter->Report( _( "Component Placement File generation OK." ), REPORTER::RPT_ACTION );
 
 return true;
 }
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] RES: [PATCH] Logic reformulation in Plot_Edges_Modules

[Wayne Stambaugh]

Patrick,

I committed your patch to the product branch r6700.  Thank you for your
contribution to KiCad.

Cheers,

Wayne

On 4/13/2016 10:53 AM, Pereira, Patrick wrote:
> Ops, sorry for my inattention.
> 
> Correction in attachment.
> 
> 
> De: Kicad-developers 
> [kicad-developers-bounces+patrick.pereira=intel@lists.launchpad.net] em 
> nome de Lorenzo Marcantonio [l.marcanto...@cz-dynamic.it]
> Enviado: quarta-feira, 13 de abril de 2016 3:19
> Para: Kicad Developers
> Assunto: Re: [Kicad-developers] [PATCH] Logic reformulation in 
> Plot_Edges_Modules
> 
> On Tue, Apr 12, 2016 at 09:16:00PM +, Pereira, Patrick wrote:
>> Hi,
>>
>> Corrections to avoid unnecessary boolean operations
>> !(!a || !b) = a || b
> 
> You just insulted DeMorgan :D Hope the code is better
> 
> --
> Lorenzo Marcantonio
> CZ Srl - Parma
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Housekeeping

[Wayne Stambaugh]

On 4/12/2016 1:09 PM, Simon Wells wrote:
> No problems here, but i was just curious, also would it not be better
> to move the os dependent resouces files to the resources folder (this
> will require a bit of effort for Info.plist but the rest will be
> easy...
> 
> for example
> 
> pcbnew.icns, pcbnew_doc.icns and pcbnew.rc Info.plistl are more
> suitable in a resources directory

I'm not sure these resources should be moved.  They are required to
build the application.  The resources currently in the resource folder
are for adding desktop and other non-build related platform resources so
they are somewhat different in their scope.  I don't have a really
strong opinion one way or the other it's just that logically the current
layout make sense to me.

> 
> Simon
> 
> On Wed, Apr 13, 2016 at 4:55 AM, Wayne Stambaugh  wrote:
>> I have a bunch of code cleaning on my todo list and want to make sure I
>> don't step on anyone's toes.  Here is the list of things that I'm going
>> to remove:
>>
>> * All of the macro code which does nothing and appears to have been
>> abandoned long ago.  I should have do this before the stable release.
>>
>> * All of the user build scripts in the scripts/ folder including the OSX
>> specific stuff.
>>
>> * The packaging folder which I believe we've discussed this in the past
>> and agreed that we could get rid of it.  There is some OSX stuff in
>> there that I'm not sure about.
>>
>> * Some of the old documentation of items that have been completed or are
>> no longer being developed.
>>
>> * The old subversion cmake files.
>>
>> Please let me know if there is anything here that I need to keep or if
>> there is anything I missed.  I do want to keep the new/ folder as there
>> is an inheritance design in there that may prove useful when the new
>> component library file format is implemented.  Once that hurdle is
>> cleared, I'll remove the contents of the new/ folder.
>>
>> Cheers,
>>
>> Wayne
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bitmap fonts

[Wayne Stambaugh]

On 4/18/2016 10:03 AM, Maciej Sumiński wrote:
> On 04/15/2016 03:41 PM, "Torsten Hüter" wrote:
>> Hi Orson,
>> thanks for your nice work. I remember that we have discussed about this 
>> subject 
>> a few years ago - in general I think it's an advantage to
>> have an alternative for the stroke font. Not for performance, but for the 
>> visual 
>> quality.
>> I'd call it rather "outline font" instead of bitmap font, because that's 
>> more 
>> general - see also
>> https://en.wikipedia.org/wiki/Computer_font#OUTLINE
>> Of course you're using a texture for the font atlas, but the origin was a 
>> outline (or vector-) font.
>> For a higher quality at small sizes you need also a font atlas with 
>> different 
>> detail levels. I did some research back then and
>> found freetype-gl the best libary for these purposes.
>> https://github.com/rougier/freetype-gl
>> Perhaps you can reuse some code from them, for instance the atlas creation 
>> or 
>> the shaders.
> 
> Hi Torsten,
> 
> I had a look at the mentioned library when I was considering possible
> ways to go about the problem. It would be great if we wanted to use a
> number of fonts, especially to give possibility to use anything
> available in current system fonts, but in our case I do not see any
> advantage over the current method. If we were developing GIMP, then I
> surely would vote for it, but I think it is enough to have one font in
> KiCad.

Please don't dismiss this idea too quickly.  We've already discussed
using freetype to allow us to use any font even in boards.  We also
already have an indirect dependency on freetype via cairo so we wouldn't
be adding much in that regard.  Until we decide to support plotting arcs
in gerber files, this probably doesn't mean much but it's still
something to keep in mind.  I looked at freetype a while back and it
appears to do a good job of providing stroke outlines for all of the
font types it supports.  This may be a less problematic solution than
having to create our own stroke fonts and rendering them.  I don't want
to repoen the font discussion but if there is a good library that solves
our problem, I'm always willing to consider it rather than spending time
designing our own solution.

> 
> Likely it also means we ought to start shipping fonts with KiCad to be
> sure that texts can be rendered properly.

This is the age old problem.  Licensing issues with fonts will most
likely prevent you from shipping or embedding certain fonts so this
issue will always be present.  This problem still exists for all office
applications even if most users don't realize it.

> 
> It is not hard to rescale font atlas to get a few different sizes,
> either manually or with OpenGL mipmapping. If we really need to limit
> ourselves to a few possible font sizes then it can be done, but for the
> moment I do not see a big gain here.
> 
> Regards,
> Orson
> 
>> Thanks,
>> Torsten
>> I have just enabled regular OpenGL mipmapping, but I do not see a
>> significant difference. I consider the mentioned text (net name on pad
>> 1, C2) to be just too small to make it readable. If you compare the
>> original font and legacy view, they have the same problem and I am not
>> sure we can do much about it.
>>
>> Regards,
>> Orson
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bitmap fonts

[Mário Luzeiro]

From: Maciej Sumiński [maciej.sumin...@cern.ch]
Sent: 18 April 2016 15:05
To: Mário Luzeiro; kicad-developers@lists.launchpad.net
Subject: Re: [Kicad-developers] Bitmap fonts

> Maybe it would be enough just to double the font atlas texture size? I
> suppose people do not spend much time staring at pads at such zoom
> level, so it should not be a major problem.

Would it be possible to limit the zoom in pcbnew? Yes.. you can zoom a lot :S 
Is there any reason for so much zoom?
If you move the chars do redraw every frame, you will be able to manual limit 
the size of the text, so it solves it.

> > mipmap_spacing_issue.png:
> > I notice for some zoom levels that there are "blur margin" effects issues.
> > I believe it may be fixed if you increase the spacing of the chars in the 
> > texture. (So you may need to decrease the font size to keep the same 
> > texture size)

> Good point, I have not noticed them before. From what I see, it is a
> byproduct of OpenGL way of mipmapping. I will have a look at it.

As the mipmap creates reduced replicas of the original texture, it will 
"interpolate" the surroundings. So when you get the texture for the quad.. it 
will "touch" the "blured" pixels of the next one.
I think it could be solved just by adding spacing between chars on the original 
texture until you stop to see the problem.

Mario
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bitmap fonts

[Maciej Sumiński]

Ok, you have a point here. It seems that if we want to have it, then we
have to switch back to storing texts in noncached container and send
them every frame. Still, it is much cheaper than drawing using stroked
font, so it should be feasible.

On 04/18/2016 04:23 PM, Mário Luzeiro wrote:
> But for fonts, you are dealing with individual chars, each char depends on 
> the position of the last char. So if you scale it you also change the 
> position of the next chars (and scale).
> I believe it will not (easily) possible on shaders to move the position of 
> the next chars based on the previous shader calculation :/
> 
> From: Maciej Sumiński [maciej.sumin...@cern.ch]
> Sent: 18 April 2016 15:12
> To: Mário Luzeiro; kicad-developers@lists.launchpad.net
> Subject: Re: [Kicad-developers] Bitmap fonts
> 
> Lines are computed once and cached in video memory and then rescaled
> using only shaders. To do the trick, for every vertex I store there is a
> vector saying in which direction a vertex should be moved and requested
> line width. In fragment shader I compute expected visible line width
> (taking into account current MVP matrix), and if it is too low I simply
> transform the offending vertex coordinate, so it is visible again. The
> same principle can be applied to fonts.
> 
> Regards,
> Orson
> 
> On 04/18/2016 04:00 PM, Mário Luzeiro wrote:
>> I was looking into your shader the shaders and had the same idea... but it 
>> is not possible to manage things like spacement etc.. because they will be 
>> present always as individual an individual (triangle or point) entity on the 
>> shader.
>> If you are able to know what text need to be render for each frame, so it 
>> would be more flexible do it on software.
>>
>> Mario
>>
>> 
>> From: Maciej Sumiński [maciej.sumin...@cern.ch]
>> Sent: 18 April 2016 14:46
>> To: Mário Luzeiro; kicad-developers@lists.launchpad.net
>> Subject: Re: [Kicad-developers] Bitmap fonts
>>
>> As you have already noticed - it is not. It may be moved back to
>> noncached container and it will be redrawn every frame.
>>
>> Another solution is to apply dynamic scaling using shaders - it is
>> already done for lines, so they do not disappear when their width is
>> smaller than 1 px.
>>
>> Regards,
>> Orson
>>
> 
> 




signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bitmap fonts

[Mário Luzeiro]

But for fonts, you are dealing with individual chars, each char depends on the 
position of the last char. So if you scale it you also change the position of 
the next chars (and scale).
I believe it will not (easily) possible on shaders to move the position of the 
next chars based on the previous shader calculation :/

From: Maciej Sumiński [maciej.sumin...@cern.ch]
Sent: 18 April 2016 15:12
To: Mário Luzeiro; kicad-developers@lists.launchpad.net
Subject: Re: [Kicad-developers] Bitmap fonts

Lines are computed once and cached in video memory and then rescaled
using only shaders. To do the trick, for every vertex I store there is a
vector saying in which direction a vertex should be moved and requested
line width. In fragment shader I compute expected visible line width
(taking into account current MVP matrix), and if it is too low I simply
transform the offending vertex coordinate, so it is visible again. The
same principle can be applied to fonts.

Regards,
Orson

On 04/18/2016 04:00 PM, Mário Luzeiro wrote:
> I was looking into your shader the shaders and had the same idea... but it is 
> not possible to manage things like spacement etc.. because they will be 
> present always as individual an individual (triangle or point) entity on the 
> shader.
> If you are able to know what text need to be render for each frame, so it 
> would be more flexible do it on software.
>
> Mario
>
> 
> From: Maciej Sumiński [maciej.sumin...@cern.ch]
> Sent: 18 April 2016 14:46
> To: Mário Luzeiro; kicad-developers@lists.launchpad.net
> Subject: Re: [Kicad-developers] Bitmap fonts
>
> As you have already noticed - it is not. It may be moved back to
> noncached container and it will be redrawn every frame.
>
> Another solution is to apply dynamic scaling using shaders - it is
> already done for lines, so they do not disappear when their width is
> smaller than 1 px.
>
> Regards,
> Orson
>



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bitmap fonts

[Maciej Sumiński]

On 04/15/2016 02:01 PM, Mário Luzeiro wrote:
> Here is the result of my test (attached)
> 
> Question: Is the text rendered every draw frame?
> 
> If yes:
> My suggestion was to clamp to a max size (in order to render the text 1:1 on 
> relation to the font pixel size in the texture) and to a minimum (or not 
> display it.. )
> See the too_big.png issue.
> I think as this is informative text it can be render dynamically and doesn't 
> not matter the exactly position / scale.

Maybe it would be enough just to double the font atlas texture size? I
suppose people do not spend much time staring at pads at such zoom
level, so it should not be a major problem.

I like when KiCad looks nice, but it is not the main objective here, so
we have to decide when it looks good enough.

> mipmap_spacing_issue.png:
> I notice for some zoom levels that there are "blur margin" effects issues.
> I believe it may be fixed if you increase the spacing of the chars in the 
> texture. (So you may need to decrease the font size to keep the same texture 
> size)

Good point, I have not noticed them before. From what I see, it is a
byproduct of OpenGL way of mipmapping. I will have a look at it.

Regards,
Orson

> Mario
> 
> 
> From: Kicad-developers 
> [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of 
> jp charras [jp.char...@wanadoo.fr]
> Sent: 15 April 2016 11:39
> To: kicad-developers@lists.launchpad.net
> Subject: Re: [Kicad-developers] Bitmap fonts
> 
> Le 15/04/2016 11:21, Maciej Sumiński a écrit :
>> On 04/14/2016 06:39 PM, Simon Richter wrote:
>>> Hi,
>>>
>>> On 14.04.2016 11:33, Maciej Sumiński wrote:
>>>
 Currently, the most expensive thing to draw is stroked text, as there
 are lots of labels on tracks and pads. To reduce the drawing cost (and
 memory requirements), texts that are not targeted to Gerber files (i.e.
 pad & track labels) might be displayed using bitmap fonts. This way, a
 single letter cost is reduced from tens of triangles to just two.
>>>
>>> Do these actually need to be stored, or can they be generated on the fly
>>> from some simpler representation?
>>>
>>>Simon
>>
>> Previously they were generated on the fly for every frame. Storing them
>> occupied a lot of memory, so I decided to generate them only when
>> appropriate (i.e. they are in the current view area and the zoom level
>> is high enough).
>>
>> Another solution that comes to my mind is some kind of
>> pseudo-instancing, where the stroked font lines are stored once and the
>> video card receives only a range of indexes to draw and a transformation
>> matrix to apply. That should be not that hard to introduce.
>>
>> Still, it is hard to beat 2 triangles per character. I am willing to
>> increase the font texture atlas resolution if people are not satisfied
>> with the outcome.
>>
>> Regards,
>> Orson
> 
> Orson,
> 
> I just tested your last version, and I find the result rather good.
> 
> Only one thing: I have some trouble to understand the criteria used to decide 
> if pad numbers and net
> names are shown or not:
> For a given pad (i.e. font size), it depends not only on the zoom level (this 
> is what I was
> expecting), but also on other things like the fact you are zooming from high 
> level to low level or
> the opposite, and the board area shown on screen.
> 
> Thanks.
> 
> 
> --
> Jean-Pierre CHARRAS
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bitmap fonts

[Maciej Sumiński]

On 04/15/2016 03:41 PM, "Torsten Hüter" wrote:
> Hi Orson,
> thanks for your nice work. I remember that we have discussed about this 
> subject 
> a few years ago - in general I think it's an advantage to
> have an alternative for the stroke font. Not for performance, but for the 
> visual 
> quality.
> I'd call it rather "outline font" instead of bitmap font, because that's more 
> general - see also
> https://en.wikipedia.org/wiki/Computer_font#OUTLINE
> Of course you're using a texture for the font atlas, but the origin was a 
> outline (or vector-) font.
> For a higher quality at small sizes you need also a font atlas with different 
> detail levels. I did some research back then and
> found freetype-gl the best libary for these purposes.
> https://github.com/rougier/freetype-gl
> Perhaps you can reuse some code from them, for instance the atlas creation or 
> the shaders.

Hi Torsten,

I had a look at the mentioned library when I was considering possible
ways to go about the problem. It would be great if we wanted to use a
number of fonts, especially to give possibility to use anything
available in current system fonts, but in our case I do not see any
advantage over the current method. If we were developing GIMP, then I
surely would vote for it, but I think it is enough to have one font in
KiCad.

Likely it also means we ought to start shipping fonts with KiCad to be
sure that texts can be rendered properly.

It is not hard to rescale font atlas to get a few different sizes,
either manually or with OpenGL mipmapping. If we really need to limit
ourselves to a few possible font sizes then it can be done, but for the
moment I do not see a big gain here.

Regards,
Orson

> Thanks,
> Torsten
> I have just enabled regular OpenGL mipmapping, but I do not see a
> significant difference. I consider the mentioned text (net name on pad
> 1, C2) to be just too small to make it readable. If you compare the
> original font and legacy view, they have the same problem and I am not
> sure we can do much about it.
> 
> Regards,
> Orson
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bitmap fonts

[Mário Luzeiro]

I was looking into your shader the shaders and had the same idea... but it is 
not possible to manage things like spacement etc.. because they will be present 
always as individual an individual (triangle or point) entity on the shader.
If you are able to know what text need to be render for each frame, so it would 
be more flexible do it on software.

Mario


From: Maciej Sumiński [maciej.sumin...@cern.ch]
Sent: 18 April 2016 14:46
To: Mário Luzeiro; kicad-developers@lists.launchpad.net
Subject: Re: [Kicad-developers] Bitmap fonts

As you have already noticed - it is not. It may be moved back to
noncached container and it will be redrawn every frame.

Another solution is to apply dynamic scaling using shaders - it is
already done for lines, so they do not disappear when their width is
smaller than 1 px.

Regards,
Orson

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bitmap fonts

[Maciej Sumiński]

As you have already noticed - it is not. It may be moved back to
noncached container and it will be redrawn every frame.

Another solution is to apply dynamic scaling using shaders - it is
already done for lines, so they do not disappear when their width is
smaller than 1 px.

Regards,
Orson

On 04/15/2016 04:02 PM, Mário Luzeiro wrote:
>> Question: Is the text rendered every draw frame?
> 
> No :/ I found / experiment it on the source code.
> 
> 
> From: Mário Luzeiro
> Sent: 15 April 2016 13:01
> To: kicad-developers@lists.launchpad.net; maciej.sumin...@cern.ch
> Subject: RE: [Kicad-developers] Bitmap fonts
> 
> Here is the result of my test (attached)
> 
> Question: Is the text rendered every draw frame?
> 
> If yes:
> My suggestion was to clamp to a max size (in order to render the text 1:1 on 
> relation to the font pixel size in the texture) and to a minimum (or not 
> display it.. )
> See the too_big.png issue.
> I think as this is informative text it can be render dynamically and doesn't 
> not matter the exactly position / scale.
> 
> mipmap_spacing_issue.png:
> I notice for some zoom levels that there are "blur margin" effects issues.
> I believe it may be fixed if you increase the spacing of the chars in the 
> texture. (So you may need to decrease the font size to keep the same texture 
> size)
> 
> Mario
> 




signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bitmap fonts

[Maciej Sumiński]

On 04/15/2016 12:39 PM, jp charras wrote:
[snip]
> Orson,
> 
> I just tested your last version, and I find the result rather good.

I have just changed one more thing: now vertex data is not stored in the
system memory, but in mapped video memory [1]. I hope it solves all the
memory related problems for now.

> Only one thing: I have some trouble to understand the criteria used to decide 
> if pad numbers and net
> names are shown or not:
> For a given pad (i.e. font size), it depends not only on the zoom level (this 
> is what I was
> expecting), but also on other things like the fact you are zooming from high 
> level to low level or
> the opposite, and the board area shown on screen.

It should be dependent only on pad size and zoom, the code responsible
for the decision is in D_PAD::ViewGetLOD() method. I will have a look at
it and see if there is another problem that I am not aware of.

Regards,
Orson

1.
https://github.com/orsonmmz/kicad-source-mirror/tree/cached_container_refactor




signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] PATCH: 3D filename resolver

[Cirilo Bernardo]

OK, I'll test on MSWin.  I can't replicate the problem on Linux and haven't
had any complaints yet from OSX.

- Cirilo


On Mon, Apr 18, 2016 at 7:40 PM, easyw  wrote:

> Hi Cirilo,
> I tested the patch r6697 in windows 8.1 64b but I still get the same error
> with KIPRJMOD
>
> to replicate the problem simply open a board that has already $ENVAR on
> its 3D module field
> i.e. (model ${KIPRJMOD}/shapes/cap_0603.wrl
>
> with the GUI select footprint, Edit Parameters
> then in 3D settings click on Edit Filename
> just edit and confirm the old path i.e. ${KIPRJMOD}/shapes/cap_0603.wrl
> and you will receive the message Invalid Filename
> that behavior is present also if you try to change it to a different path
> with $ENV on it
>
> please note that the path is correctly parsed (the model if exists is
> displayed) but it is not validated on confirmation button
> I tried both opening the kicad_pcb directly from pcbnew or opening the
> .pro and then the pcb
>
> here you can find a self contained project with KIPRJMOD var for 3D
> models, with which you can replicate the problem...
>
> https://sourceforge.net/projects/kicadstepup/files/prjs/HACK-master-R3.7z/download
>
> thank you
> Maurice
>
>
>
>
> On 18/04/2016 00.36, Wayne Stambaugh wrote:
>
>> Cirilo,
>>
>> Thanks.  I committed your patch in r6697.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 4/16/2016 6:51 PM, Cirilo Bernardo wrote:
>>
>>> Hi Wayne,
>>>
>>>   As far as I know the patch only fixes latent (unreported) bugs and
>>> improves the compatibility with previous versions of KiCad. Nick has
>>> pointed me to some users' posts regarding behavior which they considered
>>> a bug and which is fixed by this patch, but I don't know of any bugs
>>> reported to launchpad.
>>>
>>> - Cirilo
>>>
>>>
>>> On Sat, Apr 16, 2016 at 10:34 PM, Wayne Stambaugh >> > wrote:
>>>
>>>  Cirilo,
>>>
>>>  Does this patch fix any reported bugs?  I seem to remember one filed
>>>  about 3D model file paths but I cannot find anything directly
>>> related to
>>>  this patch.  I have it ready to commit but before I commit it I
>>> want to
>>>  make sure I don't have to link it to a bug report.
>>>
>>>  Thanks,
>>>
>>>  Wayne
>>>
>>>  On 4/15/2016 7:10 PM, Cirilo Bernardo wrote:
>>>  > The attached patch makes the following changes:
>>>  >
>>>  > 1. Paths defined via pcbnew->Preferences->Configure Paths
>>>  > are now included in the 3D file browser's drop-down list except
>>>  > for KICAD_PTEMPLATES, KIGITHUB, KISYSMOD, any paths
>>>  > resembling a URL, and any non-existent paths. When an
>>>  > absolute path is shortened using one of these path aliases,
>>>  > let's say 'KISYS3DMOD' then the name appears in the pcb file
>>>  > as "${KISYS3DMOD}/blah.wrl". If a user defines and actual
>>>  > environment variable with the same name, then that user
>>>  > defined variable will have precedence over the internally defined
>>>  > variable.
>>>  >
>>>  > 2. Paths relative to the current project directory are no longer
>>>  > represented as "some/path/to/file.wrl"; for compatibility with
>>>  > previous kicad versions it shall always be stored as
>>>  > ${KIPRJMOD}/some/path/to/file.wrl.
>>>  >
>>>  > 3. Various restrictions on alias path values have been removed
>>>  > since the imposed restrictions could result in corrupted user
>>>  > data (aliases are silently dropped).
>>>  >
>>>  > Overall the patch should improve back-compatibility by
>>>  > providing a ${ENV_VAR} mechanism for supporting
>>>  > different model root directories and ensuring that paths
>>>  > relative to KIPRJMOD are expressed in a way that is
>>>  > compatible with earlier kicad versions. This allows users
>>>  > more flexibility and the ability to work in a way that ensures
>>>  > 3D model files can be correctly resolved in earlier versions
>>>  > of kicad. Users who do not care about back-compatibility
>>>  > may prefer to use the newer alias system.
>>>  >
>>>  > - Cirilo
>>>  >
>>>  >
>>>  > ___
>>>  > Mailing list: https://launchpad.net/~kicad-developers
>>>  > Post to : kicad-developers@lists.launchpad.net
>>>  
>>>  > Unsubscribe : https://launchpad.net/~kicad-developers
>>>  > More help   : https://help.launchpad.net/ListHelp
>>>  >
>>>
>>>
>>>  ___
>>>  Mailing list: https://launchpad.net/~kicad-developers
>>>  Post to : kicad-developers@lists.launchpad.net
>>>  
>>>  Unsubscribe : https://launchpad.net/~kicad-developers
>>>  More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>>
>>
>> ___

Re: [Kicad-developers] PATCH: 3D filename resolver

[easyw]

Hi Cirilo,
I tested the patch r6697 in windows 8.1 64b but I still get the same 
error with KIPRJMOD


to replicate the problem simply open a board that has already $ENVAR on 
its 3D module field

i.e. (model ${KIPRJMOD}/shapes/cap_0603.wrl

with the GUI select footprint, Edit Parameters
then in 3D settings click on Edit Filename
just edit and confirm the old path i.e. ${KIPRJMOD}/shapes/cap_0603.wrl
and you will receive the message Invalid Filename
that behavior is present also if you try to change it to a different 
path with $ENV on it


please note that the path is correctly parsed (the model if exists is 
displayed) but it is not validated on confirmation button
I tried both opening the kicad_pcb directly from pcbnew or opening the 
.pro and then the pcb


here you can find a self contained project with KIPRJMOD var for 3D 
models, with which you can replicate the problem...

https://sourceforge.net/projects/kicadstepup/files/prjs/HACK-master-R3.7z/download

thank you
Maurice



On 18/04/2016 00.36, Wayne Stambaugh wrote:

Cirilo,

Thanks.  I committed your patch in r6697.

Cheers,

Wayne

On 4/16/2016 6:51 PM, Cirilo Bernardo wrote:

Hi Wayne,

  As far as I know the patch only fixes latent (unreported) bugs and
improves the compatibility with previous versions of KiCad. Nick has
pointed me to some users' posts regarding behavior which they considered
a bug and which is fixed by this patch, but I don't know of any bugs
reported to launchpad.

- Cirilo


On Sat, Apr 16, 2016 at 10:34 PM, Wayne Stambaugh > wrote:

 Cirilo,

 Does this patch fix any reported bugs?  I seem to remember one filed
 about 3D model file paths but I cannot find anything directly related to
 this patch.  I have it ready to commit but before I commit it I want to
 make sure I don't have to link it to a bug report.

 Thanks,

 Wayne

 On 4/15/2016 7:10 PM, Cirilo Bernardo wrote:
 > The attached patch makes the following changes:
 >
 > 1. Paths defined via pcbnew->Preferences->Configure Paths
 > are now included in the 3D file browser's drop-down list except
 > for KICAD_PTEMPLATES, KIGITHUB, KISYSMOD, any paths
 > resembling a URL, and any non-existent paths. When an
 > absolute path is shortened using one of these path aliases,
 > let's say 'KISYS3DMOD' then the name appears in the pcb file
 > as "${KISYS3DMOD}/blah.wrl". If a user defines and actual
 > environment variable with the same name, then that user
 > defined variable will have precedence over the internally defined
 > variable.
 >
 > 2. Paths relative to the current project directory are no longer
 > represented as "some/path/to/file.wrl"; for compatibility with
 > previous kicad versions it shall always be stored as
 > ${KIPRJMOD}/some/path/to/file.wrl.
 >
 > 3. Various restrictions on alias path values have been removed
 > since the imposed restrictions could result in corrupted user
 > data (aliases are silently dropped).
 >
 > Overall the patch should improve back-compatibility by
 > providing a ${ENV_VAR} mechanism for supporting
 > different model root directories and ensuring that paths
 > relative to KIPRJMOD are expressed in a way that is
 > compatible with earlier kicad versions. This allows users
 > more flexibility and the ability to work in a way that ensures
 > 3D model files can be correctly resolved in earlier versions
 > of kicad. Users who do not care about back-compatibility
 > may prefer to use the newer alias system.
 >
 > - Cirilo
 >
 >
 > ___
 > Mailing list: https://launchpad.net/~kicad-developers
 > Post to : kicad-developers@lists.launchpad.net
 
 > Unsubscribe : https://launchpad.net/~kicad-developers
 > More help   : https://help.launchpad.net/ListHelp
 >


 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp





___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp