vitaliymaz / vscode-svg-previewer Goto Github PK

Many SVGs can contain currentColor which will take on the color of the parent (in a DOM). We should be able to simulate that by choosing a color other than black in the previewer.

If this extension https://marketplace.visualstudio.com/items?itemName=jock.svg is active -- preview opens with that extension and this ext is ignored.

I know that this is possible, because this one https://gitlab.com/SNDST00M/vscode-native-svg-preview doesn't conflict with jock.svg

And I'd prefer to use THIS ext for preview, thanks to fact that it supports both CSS styled SVGs and live reload of preview on code change.

Thanks for the great plugin, just installed it and it does exactly what I need.

Unfortunately most of the SVG I use is for an icon sprite, so none of them have any fill information and they're all black - this makes them quite hard to see on the current background.

Would it be possible to add an option to switch to a light background to the preview.

I would love to use this extension with VSCodium. For that to work, the extension would need to be published to the open-source registry at openvsx. A guide on how to do that can be found here: https://github.com/eclipse/openvsx/wiki/Publishing-Extensions

Alternatively, the extension could be added to the publish-extensions repo as a workaround, but that would not be a good long-term solution for reasons described here.

I know it’s a few steps to follow, but please consider this! I’d be very grateful. <3

Hello 👋 I'm from the VS Code team.

Recently, we have been exploring a security feature we refer to as Workspace Trust. This feature is intended to centralize and unify a security conscious decision required by a variety of VS Code features. With workspace trust, the user will be able to declare whether or not they trust the folder that is opened in VS Code before these features are executed.

Why you should care

We want to make sure that those users have a delightful experience with workspace trust and that includes extension authors deciding how much of their extension is supported in an untrusted workspace. Custom editors are special in that if they cannot at least render in an untrusted state then they will be replaced by a lightweight message telling the user to enable trust. This means that users of your extension will not be able to see their editors and there may even be cases of data loss.

Workspace Trust experience

You can enable the feature with the following setting security.workspace.trust.enabled. Once enabled, you will see the following dialog when opening folders in VS Code.

This dialog is important for allowing the user to make a decision early and understand the impact of their decision. Once you understand the feature, you may want to customize when to display the dialog using the setting security.workspace.trust.startupPrompt.

You can follow the development of Workspace Trust and provide feedback in issue #106488.

Workspace trust API

First off, all of what I am about to say can be found in issue #120251. That issue will include discussion of the feature and any updates to the feature.

The Workspace Trust extension API is now in stable. This allowed us to release the first cut of our guide for onboarding your extension to Workspace Trust. The API is small, so here is a quick look.

You can declare your extension to provide complete, partial or no support in untrusted workspaces using the untrustedWorkspaces capability in package.json.

The following example declares that the extension is supported completely in untrusted workspaces. In this case, the extension is enabled in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": true
  }
}

The next example declares that the extension is not supported in untrusted workspaces. In this case, the extension is disabled in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": false
  }
}

The third option is to declared limited support. There are three tools provided to you when you select the limited option.

First, if you have a setting that can be configured in the workspace but requires the workspace to be trusted in order to apply the workspace value, then you can include the setting using restrictedConfigurations array property in untrustedWorkspaces object. Doing so, VS Code will ignore the workspace value of these restricted settings when your extension reads these settings values using the VS Code Workspace Configuration API.

The following example declares the settings that are restricted in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": "limited",
    "restrictedConfigurations": [
      "markdown.styles"
    ]
  }
}

Next, you can also check and listen if the current workspace is trusted or not programmatically using the following API:

export namespace workspace {
  /**
   * When true, the user has explicitly trusted the contents of the workspace.
   */
  export const isTrusted: boolean;
  /**
   * Event that fires when the current workspace has been trusted.
   */
  export const onDidGrantWorkspaceTrust: Event<void>;
}

Lastly, you can hide commands or views declaratively with the isWorkspaceTrusted context key in your when clauses.

A far more detailed guide on how to onboard which will be updated as we receive feedback can be found in issue #120251.

Rollout plan

We are planning on enabling this by default in the near future (most likely next release). To prepare for that day, we want to work with you to allow your editor to work seamlessly alongside the trusted workspace experience

Our Asks

The main features that should work for custom editors in an untrusted folder is rendering, viewing, and saving (if applicable). After reviewing your codebase, I believe that your extension doesn't rely on user contents in a way that could be taken advantage of if the files were malicious. My initial assessment would be to adopt supported:true and allow your extension to operate in untrusted workspaces.

Please let me know if you have any question or would like to meet up via voice chat as I would be happy to assist you in getting your extension ready for workspace trust!

Sending the full SVG document to the preview lets the preview handle all the compute, but is a big bottleneck because the webview postMessage() has to serialize the entire SVG document string.

As a perf boost the bytecount, SVG height and width should be computed from the main extension thread.
I can try throw something together for you..

Thanks for the nice extension! As I use dark theme for vs code, I can not see the image clearly and have to switch to the light option manually every time I open an preview. Is it possible to add an option so that the light preview background can be set as default? It would help a lot. Thanks!

Hi, I maintain VS Code's Webview API

Issue

Our telemetry suggests that your extension uses webviews and may be loading resources in these webviews using hardcoded vscode-resource: URIs. These URIs have some important limitations and don't work properly when VS Code is run in a browser. We are also making changes in the desktop version of VS Code that may cause these URIs to not work properly in future versions of VS Code.

While we are making our best effort to continue support existing webview extensions that use vscode-resource: URIs on desktop versions of VS Code, we will not able to fully support all uses cases.

Fix

To ensure that your extension continues to work in as many environments as possible—including on web and remotely—please:

• Switch to use the Webview.asWebviewUri function for loading resources.

• Switch to use the Webview.cspSource property in content security policies.

These APIs shipped around 2 years ago so they should be available in all modern versions of VS Code. You can find additional information about the issue here: microsoft/vscode#97962

Let me know if you have any questions about this change

Are telemetry events sent before or after each UI event?
Some telemetry can be a "Good Thing" - but if it is synchronous and blocking, that can kill the perf of the app.
I got a nearly seamless experience after manually commenting out all telemetry, but that's fragile and not optimal.

Hello

Can you add an option that will open svg only as a preview?
I often want to view my SVG files, but I don't need to see their code. I need preview only

Could we have some dashed box to see where the SVG bouding-box is?

Would be nice to have this nice extension published onto https://open-vsx.org/ for users of OSS version of VsCpdium to use it.

(I already installed it via VSIX file)

Hi,
I find that I often want to view the whole image, using the entirety of the window I am using. Many apps have some sort of "fit to window" support. Such a feature would be really useful!

See for example the classic win32 viewer irfanview, here:

BR!

Thanks for the great extension! A nice feature to have is to render custom fonts, either via local @font-face{...} definitions or @import(...) which would allow Google Fonts and other APIs to join the party. Currently, fonts defined in this way are skipped to fallback fonts (Times, by default).

Does not show the svg preview correctly when svg has external stylesheet.

test1.svg:

<svg viewBox="0 0 100 100" xmlns="http://www.w3.org/2000/svg">
    <link xmlns="http://www.w3.org/1999/xhtml" rel="stylesheet" href="mystyle.css" type="text/css"/>
    <rect x="20" y="20" width="60" height="60" />
</svg>

test2.svg:

<?xml-stylesheet type="text/css" href="mystyle.css"?>
<svg viewBox="0 0 100 100" xmlns="http://www.w3.org/2000/svg">
    <rect x="20" y="20" width="60" height="60" />
</svg>

mystyle.css:

svg rect {
    stroke: #006600;
    fill: #00cc00;
}

The preview shows a black square.
Opening the either test1.svg or test2.svg in chrome shows green square.

Would it be possible to clarify the license for this project with a LICENSE.txt file or similar?

It would be useful if Open Preview and Open Preview to the Side commands have default keybindings like Markdown extension.

Hello there,

Is it possible to preview the image tag with this extension? My attempts so far haven't been successful.
I'm following the MDN Example which is:

<svg width="200" height="200"
  xmlns="http://www.w3.org/2000/svg">
  <image href="https://mdn.mozillademos.org/files/6457/mdn_logo_only_color.png" height="200" width="200"/>
</svg>

But that just produces an error-image icon

The .svg previews fine in browsers. I've also tried xlink:href, and also tried <use> with href/xlink:href, no success.

Hi!
Trying this extension, I noticed that for larger images (diagrams), it renders the image "compressed" on the screen, horizontally - so fonts and everything is squeezed together. Better to see for yourself, here is an image that is opened in the extension to the left and in chrome browser to the right:

BR! /mawi

PS I may be able to share the diagram in PM

I think this extension needs some love, and there are a few things I'm missing:

• Auto open the preview when opening an SVG
• Right-click to zoom out
• A button to zoom back to 100%, and one to fill the panel
• Remove the view source button, since it opens the source that's already there on the left. Alternatively, make it focus the source code.
• A picker for the background colour/pattern

A code editor for the SVG will be nice. It could be a simple formatted editor, or more feature-rich editor. It could also just be a frame to embed the built-in text editor (if that's possible).

The preview could split into two previews: saved version on left, and edited unsaved version on right, and they could update when editing or saving.