Jump to content

Peter Werner

Members
  • Content count

    232
  • Joined

  • Last visited


Reputation Activity

  1. Like
    Peter Werner reacted to lynzrand in Support typesetting for CJK text   
    I'm a designer in China, and Affinity products are gaining popularity here because of its low price and easy-to-use tools. It would be even nicer if we can get better typesetting results for CJK text, such as dealing with CJK punctuations properly (avoid line start and end while placing punctuations (标点避头尾), as well as aligning CJK characters in grids due to their block-y nature, see example 1), and having true up-to-down, right-to-left vertical text (instead of rotating text and/or squeezing multiline text, see example 2).
    Surely I know this is going to be a tough work to figure out all the rules when typesetting CJK text and implementing them, but it would pay back greatly by gaining even more users in eastern Asia (I suppose).
     
    Examples:
    1.

    A paragraph of Chinese text in Affinity Publisher. Notice the square closing quotation mark (up) and full-width comma (down) are not directly after their contents.

    The same paragraph in Adobe InDesign. The line feed points and punctuation glyph widths are modified to fit the punctuations in line.
    2.

    A paragraph of vertical text in Adobe InDesign.

    The current workaround to create vertical text in Affinity softwares. Notice the misplaced punctuations and latin letters.
     
    To be clear, I'm using Adobe InDesign only for comparison. I'm not saying that it's perfect. In fact, it's the inconsistency of shortcuts and gestures among Adobe softwares that drew me to the Affinity family. Affinity softwares are fantasic, but it can be more fantastic if we get these features.
     
    The source of text used in examples above, and also a great reference for Chinese typesetting:
    https://thetype.com/2017/11/13290/ The greatest myth in Chinese typesetting: hanging punctuation - Type is Beautiful (Chinese webpage)
  2. Like
    Peter Werner got a reaction from JGD in Full-paragraph type composition   
    I wholeheartedly agree, but someone on the Serif team commented on the forums here a few months ago that this won't be in the initial release and will come later. It's definitely one of the features I'm looking forward to the most.
  3. Like
    Peter Werner got a reaction from rui_mac in Scripting   
    I've run into a Publisher crash yesterday that somehow involved Apple's JavaScriptCore library – I do wonder if that's an indication of something coming up 
    That being said, I'm still hoping for Python instead of or at least in addition to JavaScript. Having written extensions for different software with both languages, I found that writing extensions in Python was always quick, easy, efficient and even fun, and there are tons of great third party libraries available, whereas any kind of JavaScript extensions, particularly for Adobe programs, have consistently been a royal pain. Getting good integration into the user interface of the host applications (like adding custom menu commands or panels) has never been very robust with any JavaScript-based extensions in any application I have come in contact with. And it's so easy to learn the basics of Python that I believe anyone with JavaScript experience would be able to get started in no time.
    I realize that's a rather controversial point and everybody has their own personal preference, but I do encourage everyone to have a look at a few basic Python tutorials and form their own opinion.
  4. Like
    Peter Werner got a reaction from rui_mac in Scripting   
    I've run into a Publisher crash yesterday that somehow involved Apple's JavaScriptCore library – I do wonder if that's an indication of something coming up 
    That being said, I'm still hoping for Python instead of or at least in addition to JavaScript. Having written extensions for different software with both languages, I found that writing extensions in Python was always quick, easy, efficient and even fun, and there are tons of great third party libraries available, whereas any kind of JavaScript extensions, particularly for Adobe programs, have consistently been a royal pain. Getting good integration into the user interface of the host applications (like adding custom menu commands or panels) has never been very robust with any JavaScript-based extensions in any application I have come in contact with. And it's so easy to learn the basics of Python that I believe anyone with JavaScript experience would be able to get started in no time.
    I realize that's a rather controversial point and everybody has their own personal preference, but I do encourage everyone to have a look at a few basic Python tutorials and form their own opinion.
  5. Like
    Peter Werner got a reaction from ronnyb in Using a MIDI controller with Affinity Photo   
    The full Resolve control panel is $30k, but there are cheaper and less space-consuming panels, like the ones from Tangent, or Blackmagic Design's own recently released Mini and Micro panels, which come in at roughly $3000 and $1000 respectively if I recall correctly.
     
    They are all centered around trackballs for a traditional three-way Lift/Gamma/Gain color corrector, which Affinity currently lacks, but it would be a very useful feature even without a control panel, so it would be worth adding anyway.
     
    Other than that, in addition to MIDI, DMX (a protocol used to control theatrical lighting) might also be worth looking into.
  6. Like
    Peter Werner got a reaction from thomasp in Preference for default zoom to not exceed 100% in Photo   
    By default, all images are set to fit to the viewport when they are opened. For images that are smaller than the viewport, this leads to a zoom percentage greater than 100%.
     
    Personally, I usually prefer images not to be enlarged as it gives a wrong impression about the pixel-level quality. It prevents checking if the file is sharp, while not giving any real benefit since enlarging them does not provide any additional information, unlike in the case of larger-than-screen images. So fitting larger files by default is fine, but I find myself routinely pressing Cmd+1 every time I open a low-res file in Photo.
  7. Like
    Peter Werner got a reaction from thomasp in Preference for default zoom to not exceed 100% in Photo   
    By default, all images are set to fit to the viewport when they are opened. For images that are smaller than the viewport, this leads to a zoom percentage greater than 100%.
     
    Personally, I usually prefer images not to be enlarged as it gives a wrong impression about the pixel-level quality. It prevents checking if the file is sharp, while not giving any real benefit since enlarging them does not provide any additional information, unlike in the case of larger-than-screen images. So fitting larger files by default is fine, but I find myself routinely pressing Cmd+1 every time I open a low-res file in Photo.
  8. Like
    Peter Werner got a reaction from Markio in Scripting   
    Inkscape is by no means representative of what Python scripting looks like when it is well integrated. Inkscape's Python seems like an extremely crude API that requires you to mess with some SVG DOM, write a bunch of superfluous boilerplate and integrate a bunch of third party libraries to do anything useful. That's by no means the fault of the programming language.
    I wouldn't want to use that, either.
    See this example of what a basic script for Illustrator in Python (using COM due to lack of native Python bindings) looks like. Not very different from JavaScript, really.
    Nothing of the sort would be necessary with a proper embedded Python interpreter. You could of course mess with third party packages if you wanted to.
    As an example, I'll attach a simple graphic that I generated with Python (using the interpreter that came pre-installed with OS X). The script can render to PNG using PIL (as attached) or write an SVG for use in Designer or Illustrator. Took me a lot less time than doing something like that as a script compared to doing it by hand. I can use any gradient for colors, use an image texture to modulate the size, birth or position randomization of the particles, color the connection lines, and much more. The result can be manipulated in Designer as if it was created directly with its drawing tools.
    @MikeW:
    Nothing can be done with a programming language per se except do maths and data manipulation. Scripting always means "extending" the language with an object model. User interfaces (whether on desktop or mobile) are no different than documents, layers, text frames and cat objects in that respect. Some scripting APIs just skip the UI part (or, cough, rely on Flash or HTML), which obviously leads to a rather underwhelming user experience.

  9. Like
    Peter Werner got a reaction from Medical Officer Bones in Mask layer adjustments   
    Agreed, masks are still quite quirky. I have to admit that as much as I love the software, I was quite surprised back when Photo went from Beta to Release without addressing these.
    The Dodge/Burn tools seem to do nothing (or rather, happily operates on the blank RGB data, leaving Alpha alone), the brush tool ignores blend modes, adding adjustments with a mask selected doesn't add them to the mask automatically and requires dragging them into the right place manually and selecting Alpha from the drop-down manually (both things take extra clicks and are almost impossible to discover for a new user/Photoshop convert without research), while some filters work because they affect both RGB and Alpha (eg. Motion Blur), others simply seemingly do nothing since there is no RGB data to operate on instead of treating Alpha like RGB like in Photoshop, layers/adjustments nested into Mask layers sometimes seem to not be displayed in the layers panel (might be a display limit for nesting depth), and even though there can be multiple masks affecting one layer, there is no way to combine them in Pathfinder-type operations since the layers panel only offers the regular layer blend modes that are useless in a mask context. The Photo team also has unfortunately copied Photoshop's nonsensical 1990ies limitation that features like Color Range selection are destructive commands outputting a selection and HSL qualifiers are limited to the HSL dialog box instead of working like non-destructive adjustment layers that can be used as mask layers for any type of layer or adjustment (or in case of the latter at least allowing them to be used to generate selections).
    But while I hope we'll see some workflow, feature and usability improvements in these areas in the future, for now, the most essential features are there at least. And while they're far from intuitive, they are at least usable and have the potential to be really powerful. Already, we can do things that are impossible in Photoshop, such as applying non-destructive adjustments to masks, using multiple masks on a single layer and so on.
    By the way, in addition to any Channel Mixer workarounds, Grayscale layers can be converted to masks by selecting Layer > Rasterize to Mask, and the reverse can be done by selecting a Mask layer, right-clicking the "Mask Alpha" channel in the Channels studio panel and selecting "Create Grayscale Layer".
  10. Like
    Peter Werner got a reaction from Cédric D in Adjustment   
    You can double click each of the resize handles (horizontal and vertical ones, not the corner ones for some reason) of a text frame to fit its bounds to its contents on that particular axis.
    I think it is supposed to work for picture frames as well, but it seems broken/buggy at the moment. The frame snaps to incorrect places (tested with an image dragged in from the Stock panel).
  11. Like
    Peter Werner got a reaction from Old Bruce in No column Grid?   
    Except it would be cool if that grid also allowed for subdivisions in the other direction, i.e. not just columns like InDesign, but also rows.
  12. Like
    Peter Werner got a reaction from MrDoodlezz in Column/Row Grid and Snaping for Column Edges   
    @Aammppaa Thanks for the tip with the rotated grids for angled layouts, I'll have to look into those options!
    However, what I'm looking for in addition to these settings is a layout grid that allows me to set up guides for text columns and image positioning, such as six columns with an x mm gutter, similar to what InDesign has. It has to work in addition to the regular document grid. Just like the "Margins and Columns" settings in InDesign, but with the additional option to do the same thing also with horizontal divisions, not just vertical ones.
    For instance, it would be common for a page layout to have 7 grid columns for a 3-column page. Then text frames, sidebars, image descriptions and so on would be created spanning one or more columns of the layout grid. This can be done manually with guides on master pages of course, but adjustments are rather time consuming.
     
  13. Like
    Peter Werner got a reaction from Old Bruce in No column Grid?   
    Except it would be cool if that grid also allowed for subdivisions in the other direction, i.e. not just columns like InDesign, but also rows.
  14. Like
    Peter Werner got a reaction from Old Bruce in No column Grid?   
    Except it would be cool if that grid also allowed for subdivisions in the other direction, i.e. not just columns like InDesign, but also rows.
  15. Like
    Peter Werner got a reaction from hawk in Scripting   
    Having done my fair share of scripting in InDesign myself, I can assure you that JavaScript and the way it is integrated is everything but a smooth experience.
    You get to choose between half-hearted integration where scripts need to be run from a list on a panel where it runs once and then it's over, and a second scripting engine that keeps the script running, which is necessary for creating your own menu items that can respond to user input at any time. The latter leads to all sorts of craziness and bugs and quirks, especially when the script is run twice (which might happen randomly if you try to load it automatically with InDesign), both engines make it difficult to use shared code between scripts in separate files. Not to mention that at this complexity level, the shortcomings of JavaScript as a language are just painfully apparent (not to mention Adobe's developer tools – ExtendScript Toolkit is an abomination). I found myself cursing more than saving time and resorted to writing only scripts that I absolutely needed and without any of the user friendliness required to share them with other users.
    I've also written a vector-based particle system in Python that generates SVG files that can be opened in Affinity Designer – everything about that experience was smooth, efficient, and enjoyable, unlike fighting with ExtendScript.
    The level of control required for writing extensions for a professional graphics or multimedia software differs from small automation tasks that Apple Script is intended for. There is no doubt that one can solve complex tasks in AppleScript of course, but it's by no means well suited nor intended for that type of thing.
    Remember, we're not just looking for a way to automate quick tasks, otherwise we'd be discussing an improved macro feature. We want a solution that is easy, quick and simple with a low learning curve for simple automation tasks, but scales well for complex tasks that border on a plugin, satisfying the demands of experienced developers and giving the end users a well-integrated experience.
    If you look at professional film and visual effects software like Maya, Blender, DaVinci Resolve, Modo, TheFoundry Nuke – they all use Python, and their scripting capabilities are way beyond what JavaScript and AppleScript would usually be used for. With Maya, the learning curve for creating, say, a basic script that creates a bunch of objects in your scene is extremely low (for someone without programming experience, I'd say even easier than JavaScript). But if you want to and have the skill, you can also achieve the same level of integration that a C++ plugin would have, or integrate the software with your effects pipeline for the next StarWars or Pixar movie.
    As much as we would all love this, there is just no way that porting existing InDesign scripts will be that easy. Any developer will tell you that you can't just copy and paste code from one platform to another. The internal object models of Affinity and InDesign are different enough that you'll have to rewrite most of the code anyway. Trying to make the Affinity scripting API as similar to InDesign's as possible would severely limit its usefulness. There is no point in Serif copying Adobe's mistakes for the sake of compatibility that won't be achievable anyway.
    Not to mention that the Affinity API needs to cover Photo and Designer as well, and InDesign, Illustrator and Photoshop all have very different ExtendScript object models, so which one should the Affinity be modeled after?
    I would encourage you to take just a few minutes to skim over an introductory Python tutorial – the simplicity is kind of addictive, I think you'll like it!
  16. Like
    Peter Werner got a reaction from hawk in Scripting   
    Having done my fair share of scripting in InDesign myself, I can assure you that JavaScript and the way it is integrated is everything but a smooth experience.
    You get to choose between half-hearted integration where scripts need to be run from a list on a panel where it runs once and then it's over, and a second scripting engine that keeps the script running, which is necessary for creating your own menu items that can respond to user input at any time. The latter leads to all sorts of craziness and bugs and quirks, especially when the script is run twice (which might happen randomly if you try to load it automatically with InDesign), both engines make it difficult to use shared code between scripts in separate files. Not to mention that at this complexity level, the shortcomings of JavaScript as a language are just painfully apparent (not to mention Adobe's developer tools – ExtendScript Toolkit is an abomination). I found myself cursing more than saving time and resorted to writing only scripts that I absolutely needed and without any of the user friendliness required to share them with other users.
    I've also written a vector-based particle system in Python that generates SVG files that can be opened in Affinity Designer – everything about that experience was smooth, efficient, and enjoyable, unlike fighting with ExtendScript.
    The level of control required for writing extensions for a professional graphics or multimedia software differs from small automation tasks that Apple Script is intended for. There is no doubt that one can solve complex tasks in AppleScript of course, but it's by no means well suited nor intended for that type of thing.
    Remember, we're not just looking for a way to automate quick tasks, otherwise we'd be discussing an improved macro feature. We want a solution that is easy, quick and simple with a low learning curve for simple automation tasks, but scales well for complex tasks that border on a plugin, satisfying the demands of experienced developers and giving the end users a well-integrated experience.
    If you look at professional film and visual effects software like Maya, Blender, DaVinci Resolve, Modo, TheFoundry Nuke – they all use Python, and their scripting capabilities are way beyond what JavaScript and AppleScript would usually be used for. With Maya, the learning curve for creating, say, a basic script that creates a bunch of objects in your scene is extremely low (for someone without programming experience, I'd say even easier than JavaScript). But if you want to and have the skill, you can also achieve the same level of integration that a C++ plugin would have, or integrate the software with your effects pipeline for the next StarWars or Pixar movie.
    As much as we would all love this, there is just no way that porting existing InDesign scripts will be that easy. Any developer will tell you that you can't just copy and paste code from one platform to another. The internal object models of Affinity and InDesign are different enough that you'll have to rewrite most of the code anyway. Trying to make the Affinity scripting API as similar to InDesign's as possible would severely limit its usefulness. There is no point in Serif copying Adobe's mistakes for the sake of compatibility that won't be achievable anyway.
    Not to mention that the Affinity API needs to cover Photo and Designer as well, and InDesign, Illustrator and Photoshop all have very different ExtendScript object models, so which one should the Affinity be modeled after?
    I would encourage you to take just a few minutes to skim over an introductory Python tutorial – the simplicity is kind of addictive, I think you'll like it!
  17. Like
    Peter Werner got a reaction from R C-R in Option to remove Personas from File menu?   
    I agree that the View menu would be a much more logical place for the Personae menu items.
    As far as removing them goes, I really don't see the point – my assumption would be that anybody concerned with working quickly would be using the keyboard shortcut (Ctrl+N/Cmd+N) anyway. Besides, by the same logic, all menu items that are not used as frequently as others would have to be removed from the menu, that's clearly not feasible. Menus are an inherently finicky part of user interfaces, especially on Windows where you can't just throw your mouse curser up to the top of the screen and know you're in the menu area like on OS X.
  18. Like
    Peter Werner got a reaction from spamjim in Column/Row Grid and Snaping for Column Edges   
    I may have missed something, but it would be incredibly helpful if the snapping options recognized column boundaries as snap targets. I think this is something that should definitely be in the 1.0 release.
    Also, a grid feature for layout grids with not only support for just vertical divisions for columns, but also horizontal rows would be fantastic. It should be possible to use different grid options per spread or master page.
    Ideally, there would also be an option to also rotate this grid at an angle and have rectangular text frames, shapes, images etc. be created and transformed and snapped at that angle to make layouts with slightly rotated content really easy without the need to place nested documents (and all the ugly workarounds that come with that like duplicated styles).
  19. Like
    Peter Werner got a reaction from rui_mac in Scripting   
    I've run into a Publisher crash yesterday that somehow involved Apple's JavaScriptCore library – I do wonder if that's an indication of something coming up 
    That being said, I'm still hoping for Python instead of or at least in addition to JavaScript. Having written extensions for different software with both languages, I found that writing extensions in Python was always quick, easy, efficient and even fun, and there are tons of great third party libraries available, whereas any kind of JavaScript extensions, particularly for Adobe programs, have consistently been a royal pain. Getting good integration into the user interface of the host applications (like adding custom menu commands or panels) has never been very robust with any JavaScript-based extensions in any application I have come in contact with. And it's so easy to learn the basics of Python that I believe anyone with JavaScript experience would be able to get started in no time.
    I realize that's a rather controversial point and everybody has their own personal preference, but I do encourage everyone to have a look at a few basic Python tutorials and form their own opinion.
  20. Like
    Peter Werner reacted to Jens Krebs in Affinity Publisher Tutorials   
    People who are interested in testing a non-production beta version of a specialised professional DTP app, should in my opinion know what they are doing. I expect the tutorials for the final release to be of the same great quality as for their other app. "Failing" is a very negative word.
  21. Like
    Peter Werner got a reaction from purveyor27 in Phantom Sliders   
    In the latest public beta (1.7.0.57), sliders from some dialog boxes seem to persist on screen, even when hiding Publisher. They show on top of other applications and remain interactive, even if their owner dialog box has been closed/hidden. Quitting Publisher removes them.
    OS version is OS X 10.11.6.
  22. Like
    Peter Werner got a reaction from spamjim in Column/Row Grid and Snaping for Column Edges   
    I may have missed something, but it would be incredibly helpful if the snapping options recognized column boundaries as snap targets. I think this is something that should definitely be in the 1.0 release.
    Also, a grid feature for layout grids with not only support for just vertical divisions for columns, but also horizontal rows would be fantastic. It should be possible to use different grid options per spread or master page.
    Ideally, there would also be an option to also rotate this grid at an angle and have rectangular text frames, shapes, images etc. be created and transformed and snapped at that angle to make layouts with slightly rotated content really easy without the need to place nested documents (and all the ugly workarounds that come with that like duplicated styles).
  23. Like
    Peter Werner reacted to Ken Cope in Ability to create a template   
    Yes, that's a great idea, thanks for sharing.
  24. Like
    Peter Werner got a reaction from Adalbertus in Trapping, Knockout and Separation-Preview   
    A designer specializing in layout work who doesn't know or care about separations is an expensive accident waiting to happen. Black RGB text that prints blurry, or black text at 7pt that's not set to overprint, or images with an RGB black background which auto-separates into rich black that are placed inside a CMYK K-only black rectangle in the hope of it looking seamless – the client is not going to be happy.
    I routinely check anything that goes to print in separations preview, and one out of three times, I spot a last-minute problem that needs to be fixed. Partly this is because of idiosyncrasies of InDesign's quirky transparency flattener, but still, it's an important step in any software that helps you prevent costly situations like re-printing 500 000 copies of a document because you missed a very small but very stupid problem.
    While in my opinion not absolutely essential for a 1.0 release (a software like Acrobat can be used to check the PDFs if need be), it's definitely far from just a "nice to have" feature.
  25. Like
    Peter Werner got a reaction from Adalbertus in Trapping, Knockout and Separation-Preview   
    A designer specializing in layout work who doesn't know or care about separations is an expensive accident waiting to happen. Black RGB text that prints blurry, or black text at 7pt that's not set to overprint, or images with an RGB black background which auto-separates into rich black that are placed inside a CMYK K-only black rectangle in the hope of it looking seamless – the client is not going to be happy.
    I routinely check anything that goes to print in separations preview, and one out of three times, I spot a last-minute problem that needs to be fixed. Partly this is because of idiosyncrasies of InDesign's quirky transparency flattener, but still, it's an important step in any software that helps you prevent costly situations like re-printing 500 000 copies of a document because you missed a very small but very stupid problem.
    While in my opinion not absolutely essential for a 1.0 release (a software like Acrobat can be used to check the PDFs if need be), it's definitely far from just a "nice to have" feature.
×