If more then one SVG is used inside a single DOM, eg. inline SVGs inside SVGs or inline SVGs inside HTML documents, they share the same id namespace. So documents working perfectly fine may be broken after merging into a single DOM.
It seems needed to process the SVGs for merging in some way to replace id's with unique ones.
But how to keep all references? There may be xlink:href attributes on use tags naming id's. Then there may be stranger constructs like mask="url(#some_id)" and so on.
Is there any programmatic way to keep track of id references in an SVG document?
Related
I'm studying the DOM and there is an explanation about dom here:
A web page is a document that can be either displayed in the browser window or as the HTML source. In both cases, it is the same document but the Document Object Model (DOM) representation allows it to be manipulated.
https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model/Introduction
So can we have two different document on the same page?
According to W3 schools
When an HTML document is loaded into a web browser, it becomes a document object. The document object is the root node of the HTML document. The document object is a property of the window object.
In theory, we only have 1 document (it's under window object globally) to access the entire DOM within current HTML. In the DOM, we can have multiple elements/tags which you can manipulate via document
But document is created from DocumentHTML/Document.
The Document interface represents any web page loaded in the browser and serves as an entry point into the web page's content, which is the DOM tree.
Therefore, we can create a new one. Here is one example using new document injected into iframe
When do we need it? Well, I think it's rarely used and not recommended in most cases. If we try to create a new document, that will make HTML unorganizable with multiple DOM trees.
Even though in iframes, they have their own document objects
document.getElementById('frame-id').contentWindow.document
So I think we should not create a new one, if we can achieve our targets with the current document.
We have an existing AEM application where there are 100s of pages. On most of the pages, different css files are getting loaded via a separate network call. We need to optimize this. What I am thinking is if we can:
1. Author the list of css files on the page as a page property.
2. In our code, this page property is read and all the css files mentioned as a property value get combined and rendered on the page. Similar to what is done in css.txt file or embed property.
Please suggest.
Their are few ways to reduce the network calls for css files in AEM
1) Add the css files at the template level so that all the css files are loaded once.
2) Instead of adding the category of the clientlibs use the embed property of the clientlibs. AEM will combine all the clientlibs provided in the embed property into a single clientlib and their will be only network call. But the size of the css file may increase after combining and it will effect the page load time for the first time.
But if your requirement is to author the css files then I will suggest you have a dropdown kind of property in your dialog where all your css files are displayed and the author can select the css according to the need. Once selected then you can apply those css to the html by reading through sightly.
So, it seems you don't want to or cannot use the clientlib functioanlity which is an ootb AEM feature.
No matter what solution you choose - maybe a frontend JavaScript snippet that can decide which CSS files would be needed, or some logic that builds CSS includes at render time based on the components used in the page, or something completely different - I would strongly suggest not to put the CSS files to be used in the editor's responsibility.
If they need some additional styles to be set, use the Adobe Style System. But do not abuse page properties for CSS file configurations.
I mean "hundreds of pages" sounds like a rather small site, but it might still increase your maintenance efforts a lot, when the first people start to complain about wrong colors or font sizes...
I'm using roxygen2 to document the objects in my R package, as described in the book R packages. I want to insert some text at the top (and bottom) of the doc page for every object, saying for example, "Confidential - Do Not Release". For the HTML doc pages I could do that with a CSS content property, or by inserting some HTML of course.
So how can I modify the page headings of the doc pages rendered from roxygen2? For now I'm only interested in the HTML doc pages, not PDF, so it might be enough to insert some arbitrary CSS or HTML into every doc page with roxygen2, or Rd. Is that possible?
Ideally I'd like to find an option that I can set once globally for the whole package, since if I have to add it separately to each object's documentation, I may miss some. But if I have to add it to each object, I can live with it.
Is it possible to add metadata to a layer in Adobe Illustrator? I'm looking to pull layer data (description, etc.) into a database from layer info, after saving out as an SVG. I want to see if there is a cleaner method than adding an arbitrary text box to read separately from the actual object the metadata describes.
According to the Illustrator Scripting Reference, there's no metadata you can associate with a Layer object.
However, the Document object has a field for XMP Metadata. If you can shoehorn your metadata in there, that could be useful. (I'm not sure if that survives export to SVG, though.)
Otherwise, I think you're stuck doing something hacky, like putting the metadata into text objects. Is your objection to text boxes just that it seems inelegant? Or is it causing specific problems or drawbacks? If it's the latter, we might be able to help you come up with a better hack if you give more details about why text boxes are problematic for you.
I have a three page Word document that needs to be converted into PDF. This Word document was given to me as a template to show me what the PDF output should look like. I tried converting this document into PDF, created a PDF form and used iTextSharp to open the form, populate it with data and return it back to the client. This is all great but due to large amounts of data stored, the placeholders were insufficient and the text would be truncated or hidden.
My second attempt was to create an MVC 2 View without master page, pass the model to the view, take the HTML representation of the View, pass it over to iTextSharp and render the PDF. The problem here was that iTextSharp failed on some tags (one of them was <hr> tag). I managed to get rid of the problematic tag, but then tables were not rendered properly. Namely, the border attribute was ignored so I ended up with borderless tables. That attempt failed.
I need a suggestion or advice on the most efficient way to create a PDF document in MVC 2 which would be maintainable in the long run. I really don't want my actions to be 200+ lines long. Working directly with the Word document is not the best solution as I have never worked with VSTO so I don't quite know what it would look like to open Word and manipulate text inside of it and add dynamic data and then convert that dynamically into PDF.
Any suggestion is highly welcome.
Best regards!
One thing that I've done in the past is to save the Word file as a DOCX and unzip it since DOCX is just a renamed zip file. Within the archive open up /word/document.xml and you'll see your document. There's a lot of weird XML tags in there but overall you should get a pretty good idea of where your content is. Then just add placeholder text like {FIRST_NAME}, save the file and re-zip.
Then from code you can just perform the same steps, unzipping with something like SharpZipLib or DotNetZip, swapping placeholder copy, re-zipping and then using very simple Word automation to Save-As a PDF.
The other route is to fully utilize iTextSharp and actually write Paragraphs and PdfPTable and everything else. It takes a lot longer to setup but would give you the most control.
Q: you say "... but due to large amounts of data stored, the placeholders were insufficient and the text would be truncated or hidden"
How do you end up having to much data ? If the word template can "hold" the data in 3 pages, they should fit in 3 PDF pages.
I used to use iTextSharp to create my PDF's, but I also almost always ended up building the PDF document from scratch myself.(not really a <200 line solution) Have you considerate another library, I recently switched to MigraDoc's PDFSharp.Way simpler to use then iText, lotsa examples / docus
Just my two cents
Word documents object model is quite easy to understand. It will either contain series of Paragraphs or Tables. Using the Open XML SDK, you can iterate through each paragraph/table in the word document and retrieve it's content and styles. Then you can generate PDF document on the fly using those retrieved information. This will work under MVC too.
But if your word document contains complex elements, then it will take some more time for you to implement based on this approach. Also, this approach would only work with (Word 2007 and 2010) files.
Also, HTML to PDF options currently available in the ITextSharp library would work with only known set of tags, as far as I know.
Another suggestion is to make use of commercially available .NET components. There are lot of good solution available. For ex: Syncfusion