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.
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 recently discovered this historical document, which purports to act as a test of UTF-8 encoding for whatever application displays it.
When I paste it into my terminal (iterm2), it loads the box drawings at the end beautifully (except for a couple at bottom right):
But in both Chrome and Firefox, they are crooked and clearly wrong:
It seems the difference has to do with the width of the rendered character: for example "╲" displays in my terminal as wide as other characters such as "a", but in the browser it displays wider.
Is this a deliberate choice, and if so what inspired it? If not, where is the right place to file a bug?
EDIT
Thanks to Tom Blodget's answer, I am now aware that fonts are an important consideration. I'll clarify:
In my screenshots above, Firefox and Chrome are using Courier as the monospace font, while the terminal is using Monaco. In both contexts, the font seems to apply as much to the box-drawing characters as to the ASCII ones: when I change the font, the appearance of the drawings changes as well as that of the surrounding text.
When I switch the terminal to either Courier or Courier New, it shows the box drawings equally well -- in some ways better!
When I switch either browser to Monaco, it still shows the box drawings wrong, again from characters apparently displaying at a wider-than-monospace width.
So it still seems like the browsers are doing something wrong.
When I go to dev tools, I see the entire test is one pre element. Several fonts are being used on my system. Everything looks okay except the hatch pattern on the right.
If I hack out all of the other text, the only font used is Consolas and it looks okay. I think it's down to which fonts you have, how the browser prioritizes them, especially when it has to use more than one, and (conjecture) two monospaced fonts need not have the same width.
A terminal is likely to be less adept at using multiple fonts, instead, using one fixed one or selecting one "best" match for the required characters.
[Google Chrome 72.0.3626.96 on Windows 10.]
This is likely the same as https://bugs.debian.org/981577
If you have any old fonts installed that don't cover the unicode BOX DRAWING range, it's likely that your browser is stitching them together. While each font itself might be monospace (each glyph is the same width within the font), the combination of fonts might not be monospace (because glyph width differs between fonts), which is why the alignment fails.
I found on my system that uninstalling the legacy Bitstream Vera font resolved the issue. (Bitstream Vera has been superseded by DejaVu Sans)
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.
I've placed an image on top of a div. I'm trying to blend the image into the div (The div is a solid color). In Google Chrome, it looks great! The colors blend perfectly. In IE 7, however, the colors show a hard line even though they should be the same color! After some examination (a print screen put into paint.net to check the actual RGB values), IE 7 is actually lightning up my image.
The blend has to look seamless. Google Chrome was fine with this thus far. Any ideas why IE 7 wont display the color right?
The two browsers are using different rendering engines. There are minor differences between them in how they render graphics, particularly jpegs.
The differences are minor but unavoidable.
Most of the time it goes unnoticed; it only makes an appearance in cases like yours when you try to position it against an element with a solid background colour that is supposed to be the same.
You may be able to resolve the issue by using a different image format. Try saving the image as a PNG. PNGs tend to be rendered more accurately between the browsers than jpegs, so that might be enough to solve your problem.
If that doesn't solve your problem, you could try using PNGs alpha transparency feature to produce an image with a fade to transparent at the edge, and then overlap the background colour behind it. This will definitely give you a smooth transition, but is a bit more technical, so harder to achieve. It will also give you problems with older versions of IE (IE6 for sure, I think you'll be okay with IE7), as they had some major bugs with PNG transparency. (If this is an issue for you, there are work-arounds for this; google IEPNGFix for more)
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 ...