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.
Related
Markers in SVGs are not rendered on the GitHub website.
This happens only on the website, the Android app doesn't have the same problem.
Markdown file with the problem
The SVG was created using Inkscape.
When I noticed the problem, I changed the file to an optimised SVG (File -> Save As -> Optimised SVG) but didn't observe any changes.
Edit: The situation is thornier than I initially assumed.
Firefox doesn't display the markers at all while Chrome and Edge show them in black. The images on this page appear differently on different browsers.
I manually edited the XML to colour the markers and ended up with this file. .
But Inkscape doesn't show the red outlines on the markers.
Edit: This is not a GitHub problem as I had initially suspected but an Inkscape(+Firefox) one. Still unsure whether Firefox is responsible.
Update:
Because the browsers still do not support all SVG2 features, there is a better workaround in Inkscape to fix that issue:
Select Edit > Preferences.
From the tree on the left, select: Input/Output > SVG export
Under "SVG 2 to SVG 1.1" check the two checkboxes to use the correct direction and colors (as shown in the screenshot below).
Now save the SVG file as follows:
File > Save as.
Check the box: "Export as SVG 1.1 per settings in Preferences dialog"
Now the markers should be rendered correctly in the browsers.
Note for Windows users:
For Windows users, you need an extra step in order to enable the "Export as SVG 1.1 per settings in Preferences dialog" option. To enable it:
Select: Edit > Preferences.
From the tree view select: Interface > Windows.
Under "Desktop integration" enable the option "GTK open/save dialogs", as shown in the screenshot below:
Old answer (but still relevant)
This is a known issue (see here). A workaround is to use the following extension to color the markers:
Extensions > Modify Path > Color Markers…
MDN says, (Highlight mine)
<marker-ref>
This value is a reference to a <marker> element, which will be drawn at the final vertex. If the reference is not valid, then no marker will be drawn.
In this file, notice the attributes fill="context-stroke" and stroke="context-stroke" on the <path> in the <marker>s.
Removing them fixes the problem. Still haven't found a direct way to do this from Inkscape.
I created an SVG file, and in inkscape it looks like this:
But when I render it by a browser, the arrows get screwed up:
This (above) is the actual svg (link), and in case it renders correctly in your browser, here is how I see it (this time it's a screenshot in png):
It's the same in the latest Firefox and Chrome.
This file was created in inkscape 0.48 on Windows, and when I re-open it in inkscape, it renders correctly. Is there a way to make the browser rotate the arrows?
There are bug reports of this for Chrome, Firefox, Inkscape, and Wikimedia. It turns out that some renderers get the arrow direction wrong when just one handle, the one at the beginning of the curve, has zero length. Currently, Firefox, Inkscape, and LibreOffice Write get it right, while Chrome gets it wrong.
To create an example of such a line, draw a line in Inkscape, then add a curved midpoint. Inkscape then makes both segments Bezier curves, but the end segments have zero length handles. If you then delete the midpoint, Inkscape will try to match the curve, and will create non-zero length handles for the endpoints.
Reported as bug in Firefox in 2015, and fixed
Reported as bug in Chrome in 2015, and not fixed
Reported as bug in Inkscape in 2006, blamed on user and closed as "out of date" in 2009
Reported as bug in Wikimedia in 2015, by me
Discussion of ambiguity in SVG spec
A fix that I have noticed in Inkscape is to first select the "edit paths by nodes" option, and select each endpoint and select the option to "make the selected nodes smooth" from the path editing toolbar.
I found the solution:
The problem was that for these lines Bezier curves were used, and even though the lines were straight, it caused the problem. Once I replaced the curves with "diagram connectors", the problem disappeared.
You're using degenerate bezier curves which display as straight lines. Neither Chrome nor Firefox prior to version 38 cope with these when determining marker angles.
This has been fixed in Firefox 38 by bug 1129854. I think there's an equivalent Chrome bug too.
I think I have found an error in GE V7.0.1.8244. I create a KML route file and display it with setAltitudeMode set to ALTITUDE_CLAMP_TO_GROUND. In GE V6.2.2.6613 it displays correctly but in V7.0.1.8244 (currently beta) it does not. Same program source, same data. See attached image here:
.
Any ideas anybody other than installing an other version of GE?
This is clearly a bug in GE 7.0. A few of the elements in the KML test file are out of order but nothing to cause this problem. Even if you drop the altitude values and change altitudeMode to relativeToGround it gets worse not better. Neither DirectX or OpenGL mode makes a difference.
You can report the issue here to get any updates on the problem:
http://code.google.com/p/earth-issues/issues/list
Might be an error in elevation data. You can also see this error in the sample line example if you zoom close to the path.
Only short-term fix is reverting back to GE 6.2.2 if want to view this KML correctly, otherwise, wait for a fix.
UPDATE: Issue in Google Earth issue tracker can be found here.
It does look like a bug, rather than down grading though you could look to use one of the Google Earth extensions - specifically the gx:altitudeOffset element. From the docs...
A KML extension, in the Google extension namespace, that modifies how
the altitude values are rendered. This offset allows you to move an
entire LinearRing up or down as a unit without modifying all the
individual coordinate values that make up the LinearRing. (Although
the LinearRing is displayed using the altitude offset value, the
original altitude values are preserved in the KML file.) Units are in
meters.
This should allow you to raise the path by a meter so that the clipping doesn't occur.
It is also worth noting that...
In Google Earth, a Polygon with an of clampToGround
follows lines of constant bearing; however, a LinearRing (by itself)
with an of clampToGround follows great circle lines.
So perhaps you need to adjust your path to account for this discrepancy?
Has anybody ever had any issues with transitioning the opacity of an SVG text element? I'm using both the fill-opacity style and the stroke-opacity style to fade the text elements into and out of existence. It works fine on most browsers, but doesn't transition at all in Chrome on Mac -- the text just pops in and out all at once.
I tried setting the "opacity" attribute in addition to fill-opacity and stroke-opacity and that does seem to make it work, although now I see a weird flicker effect just before and after the transition runs. It's like it's setting it to opacity=1 for a split second before it sets it to 0 and then transitions to 1.
Another interesting thing is that other shapes (circle, rect) fade in and out just fine with nearly identical code to what I'm using with text.
This does seem to be weirdness with a specific browser, but I'm wondering about other people's experiences with opacity on text elements. Are there tricks to get it to behave consistently?
What version of Chrome are you using? I noticed a bug in Chrome dev some time ago when working on the word cloud but it appears to have been fixed as of 19.0.1077.3 dev. Perhaps the fix hasn't made it into your particular version yet?
In my case, using opacity fixed the problem temporarily. The flicker effect could be due to exponent notation not being parsed for very small numbers; you can try using 1e-6 instead of 0 to get around this.
For an animation I made some months ago I toggled the style and used webkit-transition, in combination with visibility: hidden. This seems to work well. If that doesn't work, you could try transitioning to an opacity near zero.
There are small lines appearing sometimes in front of words. In the pictures they are to the right of +syntax/ and swo and delmenu.vim.
Is this a bug or those lines mean something?
Do this happened to you before?
Would they get worse in the future?
PS: I'm using Microsoft Windows XP SP2 AMD
alt text http://img97.imageshack.us/img97/7673/picpd.jpg
EDIT: I change the font to Consolas and they disappeared. Is there a way to solve the problem while still using my favorite font, Monaco (and not turning off Cleartype)?
This is caused by cleartype font smoothing.
If you use a fixed font for gvim the problem goes away (.fon files). ttf files contain font smoothing information which gets messed up in gvim.
fixedsys renders well. There are a bunch of other ones that also work well.
An alternative is to turn off font smoothing altogher using the display properties, but that will have undesirable effects on all other applications.
This does indeed look like a rendering bug. You should report it to the gvim team. But you should also never use jpegs for screen shots - the compression doesn't work nearly as well as pngs, and could potentially introduce distortion in shots exactly like this one.
Just a guess, but it may be related to the font you are using. Maybe you could try to change it to see if these lines still appear, or disappear, or move to other lines ...