Jump to content

Search the Community

Showing results for tags 'styling'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Affinity Support
    • News and Information
    • Affinity Support & Questions
    • Feature Requests & Suggestions
  • Learn and Share
    • Tutorials (Serif and Customer Created Tutorials)
    • Share your work
    • Resources
  • Bug Reporting
    • Report a Bug in Affinity Designer
    • Report a Bug in Affinity Photo
    • Report a Bug in Affinity Publisher
    • (Pre 1.7) Affinity Range Bugs Forums
  • Beta Software Forums
    • Affinity Designer Beta Forums
    • Affinity Photo Beta Forums
    • Affinity Publisher Beta Forums

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 5 results

  1. Hello world! I do publishing as a hobby. Pro bono as a volunteer for parishes and communities. But as a result of that I have many different established "identities" to support, all with their own Colour Schemes, Layouts and typography. Colour Schemes and Layouts I can manage using Paletes, as can I typography -- but not associated fonts. Current solution is to either have all fonts always installed on the system. This is a mess, and it slows down my system and makes the font dialogs unwieldy. Alternative is using a font manager. This is also a mess, since none integrates well with Publisher and it is a painful manual exercise every time. Also, both solutions are not "portable" in the sense of "trans-portable". Thus, after long intro, here my proposal: Make Fonts "importable" like any other asset. Just import document fonts and make Publisher (and the other Affinity Studio applications for that matter) retain the font files in the document bundle so they are sent along onto other platforms. And they are automatically enabled when the document is open. And automagically do not show up anywhere outside the document. Clean, simple solution. Transparent to the user. Failproof. Robust. Intuitive. Community -- what do you think? Greetings, --Thomas
  2. As found out in this question over in the Q&A forum, Publisher does not support an equivalent to what InDesign calls "Object styles". However, to produce quality output that is consistent, this is a mandatory must-have -- styling would otherwise be so much more tedious and error-prone.
  3. Hi, I'm evaluating AD for creating SVG files in a specific format, required by an internal software. What I see so far in the exported SVG is ok. But instead of getting the formatting in the style attribute <rect id=":24W16" x="261.857" y="244.422" width="26.47" height="30.95" style="fill:#c4d8f9;"/> I would prefer to get stroke and fill like this (result of another software with it's own quirks) <rect x="259" y="214" width="32.5" height="38" transform="matrix(1,0,0,1,0,0)" id=":24W16" fill="rgb(196,216,249)"/> Any export options that allow for this that I haven't found yet? Background: the SVG will be loaded into a HTML page and custom CSS will get applied to the SVG. The inline style in the SVG has highest priority and overrules what's in the CSS. Yes, there is a workaround by making everything in the CSS !important but that is a dirty hack that I'd like to avoid. Affinity Designer is the last in a long list of vector editors I'm trying, saving as SVG seems always a bad compromise, sigh :-( Regards, Jens
  4. At the moment filler text only holds normal body text and I think it would be handy to be able to include headings (or pretty much all s´╗┐tyles such as bullets, initial words and table body) as part of the filler text, not just body text. If we had some tags (like html's <h1> and <h2> tags etc) which we could wrap around the filler text in the preferences panel, when we style each element we would be able to see the filler text change accordingly, not just the body text.
  5. Rightnow exporting to SVG has all styles inline on all seperate svg-elements. And elements don't have classes or IDs. Using SVGs on web and making interactive animations on a daily basis this way it's impossible to animate elements and use external stylesheets without having to manually add classes and IDs to each element and remlve all inline styling in a text-editor after each export. I don't like to say it, but that makes this workflow impossible to use. Having to stick to inline styling inside the SVGs is another problem: - These days inline-styling is a big nono and validators throw penalties if inline styline is being used. The preferred way is internal style department, or use with external stylesheets. - A lot of layouts use the same styling on multiple elements. With inline styling all these styles got copied for all elements, resulting in a way larger SVG file then needed because of a lot of repetitive redundant data. This can easely be avoided by adding classes to the SVG elements and having one style-rule inside the general section for each different style. That makes the export a lot more efficient and makes it easier for developers like me to just copy the generated styles and move them to an external stylesheet if needed. - When styling is in the general <style> tag inside the SVG, a developer only have to change 1 stylerule if something needs to be changed instead of having to change all objects having all the same inline-styles - Because there are no classes nor IDs added to elements, we are unable to animate the elements with javascript, or again, we have to add IDs to all elements we want to animate each time after an export... A little bit like the Adobe Illustrator advanced settings offer, but that could even be improved to keep the SVG output as small as possible: My suggestion would be to add this to the SVG exporter settings: - A checkbox to add IDs to SVG elements where the layer-name starts with an asterix ('#'), followed by the name of the layer/curve. That way we can decide wich elements get IDs so we can address these elements later with Javascript to animate and so on. And with this we also prevent adding IDs to all elements in the SVG (resulting in a large SVG file with a lot of unused, redundant IDs). And when no # is add to any layer, no IDs are being written to the SVG. So full control here I'd say. - An option to choose one of the following for the SVG Export: - Use inline styles - Put styling inside <style> tag (recommended - mostly resulting in smaller files and less redundancy) (Perhaps to be complete even a: - Put styling inside svg attributes (but not my taste ) ) When a user picks 'Put styling inside <style> tag' the elements get a class attached with the styling in the general <style> tag inside the svg. Long story short: for real / advanced usage of SVG on the web for web development, interactivity and animations (by css and javascript), these options are indespensable! It would be very much appreciated if Affinity developers could look into this! Thanks a lot!
×

Important Information

These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.