3.0.0 offers a number of changes since 2.8.1, including many refactoring
ones meant to make the code more maintainable and leverage current standards
for more readable and semantic code, as well as a good number of fixes and
enhancements.
Please see the CHANGES file (or the Git history or Github tracker) for more
detailed descriptions of individual changes than that provided by the
below summaries.
Concomitant with switching to npm (semantic) versioning, future releases
should be added for any changes on a more frequent schedule.
There were also the following breaking changes. Not included among these are
those handful of breaking changes which only applied to those adopting
3.0.0 pre-release versions and which are marked as
"Breaking change (prerelease)" in CHANGES).
A number of changes were made to improve modularization.
If you were modifying source files directly, the module format has now changed
to ES6 Modules. This allows us to specify, in a standard fashion, all of
the external dependencies of a file, without any "magic" variables appearing
in the code with no indication of their source (unless they are browser
globals which should be well-known). Use of modules also avoids the need
to keep track of dependencies non-contextually within the HTML and allows us
to avoid polluting our HTML with additional script tags.
File names were also changed. See "Other breaking changes" for these.
Note that compilation no longer occurs with a Makefile but is handled by
Rollup, a library for bundling ES6 Modules. Our Rollup routine also
handles applying Babel and minification.
Note that while the number of script tags in the HTML has been reduced,
certain polyfill files (dom-polyfill and @babel/polyfill) have now been
added and are required for older browsers. They could be dropped in the
future once browser support is available or if you are only targeting
browser versions that have no need of them.
For ES6 Modules being available as a distribution option, see "Enhancements".
The jQuery files have not been added in ES6 Modules format, however, because
they do not have such a distribution and adding an import in source which
converts them to ES6 Modules through plugin would require compilation
whereas we'd prefer that at least the modular editor file be able to work
without compilation for faster debugging (note, however, that rather than
importing our external npm dependencies directly from node_modules, we
have a copy-deps script for copying these files into our repository, so
experimenting on these files should probably be done within theeditor/external directory and such changes must not be committed unless
the source packages are also updated and the copy-deps routine brings them
in).
The file redirect-on-lacking-support.js has not been bundled with the mainsvgedit-config-es.js script so that browsers not supporting SVG are
redirected faster (and, in the same vein as polyfills, it may be more
logically consistent to add this external to the main code anyways).
The file redirect-on-no-module-support.js, which redirects when module
support is not available, is not bundled for the same type of reason.
Unlike version 2.8.1 which had a config-sample.js file which needed
to be copied to config.js in the same editor directory, in version 3.0.0,
things work out of the box by pointing to the pre-built config files (also
an advantage for our use of Github-based project hosts like
raw.githack.com), but these config files have been moved out of theeditor folder and are looked for in the parent directory (project root
if using the editor within our repository).
These files also now have different names (svgedit-config-es.js
for svg-editor-es.html and svgedit-config-iife.js for svg-editor.html)
for a measure of namespacing.
This move is intended to allow config to be stored semi-independently
of editor files.
Also note that while the config file was optional in 2.8.1, the config
file in 3.* includes (or for, the ES version, imports) all of the main
SVG-Edit code, so the file (or one like it) cannot be omitted. This has
the advantage of avoiding an extra script tag and for the non-ES version,
an extra HTTP request. But if you are working with the non-modular HTML
and are not running the build routines to compile ES to non-modular
JavaScript, you will be required to directly modify your config within
the large non-modular, bundled JavaScript config file that includes most
of the SVG codebase.
The build routines include npm run build-config to convert the
JavaScript config to non-modular form, npm run rollup to convert the other
source files to non-modular form, and npm run build-html to build the
non-modular HTML out of the modular HTML (all of these are run duringnpm run test-prep, or if you want to run the tests, also as a part ofnpm test and npm run browser-test).
In version 2.8.1, one could place a custom.css file in the same directory
as the editor and it would be used.
The default is now looked for in the parent directory of the editor HTML
and is expected as svgedit-custom.css.
You may change the stylesheets which are loaded by changing the default
JavaScript stylesheet config (see the
"JavaScript config file breaking changes" section for the location of
these files). The default behavior is equivalent to this:
svgEditor.setConfig({
stylesheets: ['@default', '../svgedit-custom.css']
});
...which indicates that all default stylesheets will be loaded and then
one's custom file. You may omit either of these and/or add your own.
See "Other breaking changes -> HTML" for removal of the "scoped"
attribute on a stylesheet within the HTML.
With extensions and locales now also expressed as ES6 modules in source
(see their respective breaking changes section below), the non-modular
versions of these files have been compiled into the new dist directory,
and in order to avoid path resolution problems, the config propertiesextPath and langPath now have different defaults, depending
on whether a module environment is detected or not.
The non-modular versions will now default to ../dist/extensions/ and../dist/locale/, respectively, whereas the modular version will use the
old default paths (extensions/ and locale/).
Also, since we have not copying extension icons over to dist and the path
resolution of extension icons would otherwise break, we have now added new
a config property, extIconsPath, distinct from extPath, which points
by default to extensions/ for both modular and non-modular environments.
And because our dependencies canvg and jspdf are now building from module
and would break as a result of this move as well, we have added the configcanvgPath and jspdfPath which default respectively to canvg/ andjspdf/ in modular loads and to ../dist/ for both path types within
non-modular loads.
(imgPath and jGraduatePath remain unchanged since they, as withextIconsPath, are not looking for module-expressed files.)
Locale files are now formatted as ES6 Module exports (rather than as
calls to svgEditor.readLang).
In order for their value to be discovered when compiled and loaded
in a non-modular context, in such contexts they will be auto-defined
as global variables (as "svgEditorLang_" followed by the
locale file name with any hyphens replaced as underscores).
In the spirit of modularization and only loading what is needed,
locale strings pertaining solely to extensions were moved toeditor/extensons/ext-locale/<extension name>/<language code>.js.
A new method, importLocale, is passed to extensions (see
"Summary of enhancements -> APIs") which can load locale files within
this hierarchy, requiring no arguments if relying on the detected locale.
The npm run rollup routine (also a part of npm run test-prep or
the full test routines) will build any properly named and formatted ES6
Modules locale file into a non-modular file within dist/locale.
Extension files are now formatted as ES6 Module exports (rather than as
calls to svgEditor.addExtension). The latter may still be used, but
support for passing an object (with a callback method as an init function)
is not (callback may be present on the return object of extension init
method, however).
In order for their value to be discovered when compiled and loaded
in a non-modular context, in such contexts they will be auto-defined
as global variables (as "svgEditorExtension_" followed by the
extension file name with any hyphens replaced as underscores).
The name supplied as the first argument to addExtension should instead
be expressed as a property on an object exported by the extension (or
it can be omitted to default to a name derived from the file name; this is
only used as a unique identifier).
Any init function previously supplied as second argument to addExtension
should be expressed as an init method on the object exported by the
extension, and it should return what the init function had been returning.
Its this value will be set to the editor object.
For the object returned by init, invocation of any callback method
will also be invoked with the this value set to the editor object.
The npm run rollup routine (also a part of npm run test-prep or
the full test routines) will build any properly named and formatted ES6
Modules extension file into a non-modular file within dist/extensions.
See also "Locale breaking changes".
exportWindowName for filename and changedownload to svg.pdf, distinguishing from other downloadsscoped attribute from stylejquery.js to jquery.min.jsextensions/mathjax/MathJax.js to extensions/mathjax/MathJax.min.jssvg-editor.js,svgcanvas.js, and polyfills with "SVG" in actualaddSvgElementFromJson() to addSVGElementFromJson,changeSvgContent() to changeSVGContent())window.svgCanvas and svgCanvas.ready (usesvgEditor.canvas and svgEditor.ready instead)canvg to extensions (have them import)getPrivateMethods which is passed toassignAttributes, addSVGElementFromJson,call, copyElem, findDefs, getElem, getId,getIntersectionList, getMouseTarget, getNextId, getUrlFromAttr,hasMatrixTransform, matrixMultiply,recalculateAllSelectedDimensions, recalculateDimensions,remapElement, removeUnusedDefElems, round, runExtensions,sanitizeSvg, setGradient transformListToTransform (and mistakentoString export)newEmbeddedSVGEdit; for ext-imagelib, change to an object-basedsvgcanvas.setUiStrings must now be calledsvg-editor.js in order to get strings (for sake of i18n)path.js alone, it must also have its setUiStringsRGBColor must accept new; readLang no longer callssetLang (locales need not call this anymore anyways; it will bestoragePromptClosed state boolean in favor ofstoragePromptStateArrows to arrowsoverviewWindowGlobalsext-imagelib, theext-xdomain-messaging)svgedit=3) within their URL (a flag, if not present, which they areX-Frame-Options to "sameorigin" makes it unusable on our endopenclipart-es.html (and auto-converted file,openclipart.html) within editor/extensions/imagelib for aSince 2.8.1, there have been a number of fixes. Here is a summary (though
we do not include regressions made during the 3.0.0 prereleases which
have since been fixed; search CHANGES for "regression" for these):
imgLibs config origins for messagingtoXml utilitylang and dir for localeslangReady changesstoragePromptState has seenlangReady including the storage extension possibly having set astoragePromptState of "waiting"exportWindow blocked; avoid errorURL is not defined; polygon/polyline in PDF export; see alsoincludeWith as well as toolbarbuttons; ensure line tool shows assupportsPathInsertItemBefore and supportsPathReplaceItem); layer fixes;convertPathrx and ry on ellipses to allow disablingext-connector of 2 connecting elementsremoveFromSelection length issues; avoid errorstspan passed to getGradient; avoid race condition in applying arrowsMath.precision pseudo-global insvgEditorReady when canvas is ready and viarasterExport without imgTypelocalStorage or contentDocumentAccess-Control-Allow-Origin header andallowedOrigins with * or the given origin(s)localStorage, as islocalStorage access (e.g., context menu cut).getInsectionList;supportsNativeTransformLists detection; save/export;tspan having no getBBoxsupportsGoodTextCharPos; force PDF download in Chromename for moinsave; error during resize with MathML; add imagesextIconsPath; extensionincludeWith flyout button conflicts; avoid erring if inradius is NaNmouseup triggering forjquery.jgraduate.jshttps, adding ofpath.js strings and canvas notifications; more i18npopupWindowBlocked; update saveFromBrowserhttpsaddSvgElementFromJson capabilities;addSvgElementFromJson tonamespace property;extensions_added event; make setStrings public on editor formessage event to relay messages; return promiserasterExport, exportPDF, and embedImage; addpointsAdded canvas event; supply importLocale to init,langReady and addLangData for extension locale loading; allowgetBBox and loading time; remove unused scripts,setSvgString, return false earlier if elementpoints attribute for free-hand pathpackagist.org; unpkg.com andraw.githack.com; for Github.io, add latest directory for hostingxdomain-svg-editor-es.htmlxdomain-svg-editor.html files are now available which possess defaultsvg-editor-es.html HTML (for modern browsers only; otherwise, use one ofsvg-editor.html file) and also separate versionsxdomain-svg-editor-es.html; make SpinButton plugin independent ofdist. There is anpackage.json file, for the sake of minimizingmodule property and the UMD distribution is pointedmain.stylesheets config for indicating custom"@default""@default" to exclude them).HistoryRecordingService, Command base class,layer.js); variousclass,includes, destructuring, object shorthand, arrow functions), preferconst and then let and place closer to used block, add favicons;ChildNode/ParentNode; use new Event constructorsall_tests.html for iframe size; comment out unused jQuery SVGsvgcanvas.js without an editor)