I am using Gimp python-fu plugin. The plug-in written correctly renders a text block:
(GIMP_UNIT_POINT = 3)
titleBlockLayer = pdb.gimp_text_layer_new(img, title, <font_name>, 40, GIMP_UNIT_POINT)
but only if gimp is invoked from the X window manager (or a terminal window) when logged in on the computer's console (Fedora, various releases, same behavior; various releases of GIMP, same behavior).
However, when logged in via ssh, (using X11 forwarding to display locally), the fonts are rendered HUGE by comparison.
I am confused because (supposedly) the same login .profile and .rc files have been run regardless.
Does anyone have a clue as to what/where/how GIMP determines what a POINT means, because it is obviously not coded in but dependent upon some resource file.
For Gimp a point is 1/72 of an inch, according to the doc of gimp_text_get_extents_fontname() in the PDB browser:
If you need to display a font in points, divide the size in points by 72.0 and multiply it by the vertical resolution of the image you are taking into account.
Experimentally, when using points in gimp_text_layer_new() the size depends on the image print definition. This value can depend on user settings (72DPI by default) but you can control/set it using gimp_image_get_resolution(...) and gimp_image_set_resolution(...). What bothers me though it that it seems that at least on my Ubuntu 16.04 gimp_text_layer_new() works in inches and not in points (at 72DPI, points and pixels should be equivalent), so I would stick to using pixels and to the point<->pixels conversions using the image resolution.
Btw, what are the versions of Gimp and the Pango and Cairo libs on your various systems?
Edit: Possible explanation: it appears that in recent versions (since 2.8 at least), gimp_text_layer_new() accepts more than units than just pixels and points. It also takes millimeters, inches, and picas. So it's no longer 0 for pixels and 1 for points, and you can use the predefined UNIT_* values. The catch: 1 is no longer the value for points but is now the value for inches:
UNIT_PIXEL=0
UNIT_INCH=1
UNIT_MM=2
UNIT_POINT=3
UNIT_PICA=4
Related
Following an upgrade from Inkscape 0.91 to any newer version I found that it broke the scaling on a number of my objects which are used for interactive display.
It appears a change in the DPI setting from 90 to 69 is the issue.
When opening some of my old drawings I get a dialogue box prompt asking which action I should take; Having tried all of those with none giving me the expected (working) output.
But not all of my drawing files would trigger this dialogue but they would still have there objects rescaled on load/save.
I also tried updating the version number in the .svg file manually but this didn't work either.
How can I work with my original files but gain the rewards of the newer(est) version(s) of Inkscape?
It turns out I was not alone in this problem. After much searching I found this thread over on the Inkscape forum.
To summarise and make it easy for people to find without wading though all the posts there are two things you need to do/check in order to upgrade without issue.
Install the new version to a different path if you are able.
Backup your original files.
With your favourite sane editor open the original .svg file directly and observe the header section;
inkscape:version="0.91 r13725"
That should be replaced with the version of Inkscape you are upgrading too. In my case it is;
inkscape:version="1.0 (4035a4fb49, 2020-05-01)"
Next look for the height and width settings and note they may not have a unit defined as in my case;
width="10000"
height="800"
Check in your original drawing what scale you had been using for your page size. It could be px, mm etc. The update the height/width section to include those units as shows below;
width="10000px"
height="800px"
Save the edited .svg file.
You should then be able to open/work on your old drawings in the current version of Inkscape without breaking scaling and display compatibility.
I've been building a website under Ubuntu 17.10 and use Firefox and Chromium for testing. The two browsers show quite different colors (not only for images but all colors) and I always thought that it is Chromium which for some reason wrongly over-saturates them, so up until now I always chose colors that looked right in Firefox.
But I'm starting to get more and more complaints about the website's background being too purple - which it shouldn't be in my opinion as only the blue component of it's color (#eeeeff) is "elevated", but it has reached a point that more people are seeing it as purple than blue, what makes me confused.
This is the aforementioned color displayed in Firefox (left) and Chromium (right).
And this is how I see a website:
The difference is quite large (notice how even the favicon is different) and I'm asking you to tell me which one is the browser I should trust when choosing the colours of my websites and whether I could do something to avoid it being displayed so differently in different browsers.
(There are some users that see the overly saturated colors in Firefox too. So now which is the right one, really?)
Another option is to open chrome://flags/ and select the option sRGB on the Force color profile item.
By using this setting instead of disabling the Use hardware acceleration when available, you don't lose some nice features like the 3D view on Google Maps.
Solution found here: https://www.reddit.com/r/Fedora/comments/74h5yh/blue_shows_as_purple_in_chrome/
Using GPick as a Color Picker and calling a Website with Color Hexcode like
http://www.color-hex.com/color-palette/54430
I see, that Firefox renders the RGB Colors exactly, meaning GPick identifies the same Hex Code from CSS.
Whereas Chromium renders some kind of differnt color.
You can call
chrome://flags/#force-color-profile
and set the Color Profile in Chromium to sRGB, so the rendered Color from Chromium is identified the same as the HexCode with GPick.
If you disable 'Use hardware acceleration when available' in Chromium Settings and relaunch, Chromium displays colors correctly. When turned on, Chromium colors are off. I consider this as a workaround until Chromium color management issue with hardware acceleration is resolved.
With the other two colours being equal, your colour is right in the middle of "blue territory".
If you convert it to HSL and look on the hue line, you can see it is right in the middle of the "blue" frequency range.
Consequently, any hint of green or red is incorrect.
I have some applications, but not all, that "magically" scale up forms by a factor of 1.23 when I open the forms in the RAD IDE. For example, a form width of 947 pixels suddenly jumps to 1166 pixels. It is suspiciously-close to a pixel ratio of 120/96 (a ratio of 1.25), but the scaling is consistently closer to 1.23 (as judged by larger integer ratios derived from, for example, the form width and height).
I can look at the .dfm file and see the original numbers, whereas in the IDE, the values have been altered (e.g. height and width expanded, control positions adjusted, and font sizes increased).
I know that scaling and dpi is a minefield, but I've not (to my knowledge) changed any related settings.
For both the affect and non-affected projects, forms have the Scaled property set to "true" and the PixelsPerInch property is set to 96. My development machine has its screen resolution set to 100%. This is the setup that is supposed to avoid these issues.
I have searched through the project and IDE configuration files in a fruitless effort to find out what might be different about a project that has this issue, vs one that does not.
The affected (and unaffected) projects are all ones that have been in development for years - it is only in the last week that I have observed this behaviour. To my knowledge (I am sole developer), I have not made any code/configuration changes that relate to scaling, dpi, etc.
Does anyone have any idea what might be happening?
Although I am using CBuilder XE3, I've tagged this question with Delphi XE3 as well since I'm thinking that this is a RAD Studio issue.
EDIT 1: I've also noticed that for each modified control, the IDE throws in the following additional lines (i.e. in addition to modifying Top, Left, Width, Height, and Font.Height):
Margins.Left = 4
Margins.Top = 4
Margins.Right = 4
Margins.Bottom = 4
and for TImages, it also adds
ExplicitWidth = <nnn>
ExplicitHeight = <nnn>
EDIT 2: Curiously, when the IDE scales the form it does not flag the form as modified - i.e. the form appears unmodified until a "real" change is made (for example, repositioning a control). If the form is opened a second time after saving with the modified scale, no further scaling occurs - it seems to be a one-time effect, but there does not seem to be a "unasked-for-scaling-accomplished" flag in any configuration file :)
I draw some text on screen using ID3DXFont::DrawText. This text should be displayed the same regardless of screen resolution.
For example, if screen resolution is low, text wrapped and when it is higher text is not wrapped. How can I avoid such situation? I want text size to be connected to screen resolution so if resolution is lower I want the text to be relatively smaller so that no wrapping happens. Is there any way?
Thanks in advance
Below is a logical solution. It doesn't have any of the code or procedures needed to make work in direct X but having done something similar outside of DirectX I wanted to share the logic
Working on whatever default screen resolution you want set the font to be the size needed.
Find the percentage of the screen height the font size you chose takes up.
Then having stored that value when you go to render again, in the final version of the program, calculate the font size based on the screen size and the percentage
What I was working in had functions like GetTextHeight and properties on the font size to allow you to set the height (which in turn set the font size appropriately). So if can find anything similar to this in DirectX than this could be a route for you to take.
So I have two images set to fill the screen - one at 320x480 (iPhone 3) and the other at 640x960 (iPhone 4).
img.png (320x480)
img#2x.png (640x960)
In Interface Builder, I have img.png set to fill the view (it shouldn't be filling the iPhone 4 view, though, right?), and when I build and run, it is notably too small.
So, when I do the opposite, setting img#2x.png as the img, a giant blue question mark fills the view. The project still builds and the image fills the screen, but is very pixelated as if it has been rescaled. It shouldn't have been rescaled, though, as it is the higher resolution.
Now using...
img.png (640x960)
img#2x.png (320x480)
I've also tried switching which file takes the #2x suffix, but that has not helped either. With the smaller file taking the #2x suffix, and setting the image view to img.png, it shows up way larger than the view canvas, but way too small when on the phone. With the smaller file still having the #2x suffix, I tried switching the view to the new img#2x.png and once again got the oversized, pixelated question mark in IB and a low res full-screen image when deployed to the phone.
I also made sure that my view size was set to 640x960 in the size inspector. What else should I be doing?
Don't use #2x when specifying the image name. Just use the base name of the image (so in your case, just img). iOS will do the magic behind the scenes to use the 2x version if it's on a retina display and the regular version otherwise (including when you use a xib to lay out your interface).
The displayed dimensions of the image will always be the dimensions of the non-2x image. The retina display just displays 2 pixels for every 1 which is why the scale is 2.0 and you have to double the dimensions of the original image. So your view size in IB should be 320x480.
Edit
If IB is being finicky, especially in Xcode 4, just try deleting the xib and starting over. Sometimes it gets a bit corrupted and doesn't know what to do with itself. I've had to do this on one or two occasions, and it seems that it worked for the OP as well.