Igor
I was wondering the following: ? But TextStyle is not about strikefont?
Stef
On 04 Apr 2014, at 02:55, Igor Stasenko siguc...@gmail.com wrote:
Okay, i think i got it..
Here is what happens:
- the font size is usually specified in points, not x@y points, but
typographical points,
I don't think there is any way for the VM to know the #pixelsPerInch of the
display, regardless of the display resolution.
There is no api in the OS for that? It would be really strange that we cannot
know such information.
Maybe that implies that some
calibration would be needed in the
On 4 April 2014 08:33, Pharo4Stef pharo4s...@free.fr wrote:
Igor
I was wondering the following: ? But TextStyle is not about strikefont?
TextStyle contains so many different things..
Stef
On 04 Apr 2014, at 02:55, Igor Stasenko siguc...@gmail.com wrote:
Okay, i think i got it..
On 4 April 2014 08:35, Pharo4Stef pharo4s...@free.fr wrote:
I don't think there is any way for the VM to know the #pixelsPerInch of
the
display, regardless of the display resolution.
There is no api in the OS for that? It would be really strange that we
cannot know such information.
Woohoo! Works for me. You made my day.
In regards to determining the DPI of the display, can't we just set that as
a preference with a default value of 96? That would satisfy 98% of cases.
We could also add a primitive that would allow the VM to have its say
(e.g., retina display on MacOS). When
Pharo4Stef wrote:
I don't think there is any way for the VM to know the #pixelsPerInch of the
display, regardless of the display resolution.
There is no api in the OS for that? It would be really strange that we cannot know such information.
This is the best article I
Cool. I just loaded the latest NB and Athens (as Igor sent around) but my
image is not fully up to date. I'll try downloading a new one and reloading
my work from packages. I just wanted to make sure that this was worth the
effort. If that doesn't work, then I'll send Igor my image.
Cheers,
Jeff
Okay. One more time.
This is interference between Cairo and Freetype plugin..
if you using same font as rest of pharo (drawn outside of Athens)
and then the very same font for rendering with Athens,
then you will get weird font artifacts,
because in-image freetype code uses different scale units
Okay, i think i got it..
Here is what happens:
- the font size is usually specified in points, not x@y points, but
typographical points,
which is
1/72 inch
TextStyle pointsToPixels: 14
TextStyle pointsToPixels: 14 = 18.668
pointsToPixels: points
^points * self pixelsPerInch /
On Fri, Apr 04, 2014 at 02:55:01AM +0200, Igor Stasenko wrote:
there is one caveat, that if you really want to see exactly , say 16 points
sized font on your screen,
it is not possible without knowing the display resolution - how many pixels
in one inch (hence
#pixelsPerInch ).
Is this supposed to fix the font rendering problem or some other font
problem? I tried it and it doesn't seem to help the rendering problem.
Cheers,
Jeff
On Tue, Apr 1, 2014 at 6:27 PM, Igor Stasenko siguc...@gmail.com wrote:
okay i uploaded updated configs for NativeBoost and Athens into
On 02 Apr 2014, at 14:46, J.F. Rick s...@je77.com wrote:
Is this supposed to fix the font rendering problem or some other font
problem? I tried it and it doesn't seem to help the rendering problem.
normally it should fix the font PrObLem
can you check that you loaded the latest NB?
On 2 April 2014 14:46, J.F. Rick s...@je77.com wrote:
Is this supposed to fix the font rendering problem or some other font
problem? I tried it and it doesn't seem to help the rendering problem.
send me your image , pls.
(and provide doit to reproduce problem, i will try it on my linux box)
I have followed the discussion from very far.
But thank you guys for considering this important font problem.
I will offer some beers at esug, I promise :-)
Alexandre
On Apr 2, 2014, at 7:09 PM, Igor Stasenko siguc...@gmail.com wrote:
On 2 April 2014 14:46, J.F. Rick s...@je77.com
okay i uploaded updated configs for NativeBoost and Athens into official
repositories for these projects.
Gofer new smalltalkhubUser: 'Pharo' project: 'NativeBoost';
configuration;
load.
ConfigurationOfNativeBoost loadDevelopment.
Gofer new smalltalkhubUser: 'Pharo' project: 'Athens';
Ookkayy..
so, current status:
- finally we got an agreement that big red square because of font loading
issues and font rendering artifacts is two separate issues.
Thanks!
- i am not going to address font-loading issue here and now.. (because we
spent time on it earlier today with Stef already
https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-different-platforms
On 28 March 2014 16:42, Igor Stasenko siguc...@gmail.com wrote:
so, the quick and dirty fix is to put:
CairoGlyph classbyteAlignment
NativeBoost platformId = NativeBoostConstants win32PlatformId
On 28 March 2014 16:01, Igor Stasenko siguc...@gmail.com wrote:
Ookkayy..
so, current status:
- finally we got an agreement that big red square because of font loading
issues and font rendering artifacts is two separate issues.
Thanks!
- i am not going to address font-loading issue here
Hi,
On Fri, Mar 28, 2014 at 4:01 PM, Igor Stasenko siguc...@gmail.com wrote:
Ookkayy..
First of all, thanks a lot for offering a fix for the font problem! This
was a critical issue for Moose.
so, current status:
- finally we got an agreement that big red square because of font loading
thanks Igor.
I’m trying to look at the font reloading bug.
On 28 Mar 2014, at 17:19, Igor Stasenko siguc...@gmail.com wrote:
https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-different-platforms
On 28 March 2014 16:42, Igor Stasenko siguc...@gmail.com wrote:
so, the
20 matches
Mail list logo
