Jump to content
You must now use your email address to sign in [click for more info] ×

Mark Oehlschlager

Members
  • Posts

    634
  • Joined

  • Last visited

Everything posted by Mark Oehlschlager

  1. @garrettm30 It's a good point. Some of these attributes do not fall clearly into one class or another. Sorting these attributes out into separate "Character" and "Paragraph" buckets can seem arbitrary. For example, although kerning is quite specifically about adjusting the relationship between two characters, tracking is perhaps in a grey area, but mostly applied on a paragraph level rather than a word or phrase level. Nevertheless, approaching the matter from the practical perspective of a designer / typesetter, one thinks of setting paragraphs as a basic unit of design. A complete foundational thought is "Avenir, Bold, 12pt over 14pt", and the software interface should make it easy and convenient to enter that basic information in one panel, not separated over two or more panels. Any tweaks at the character level (e.g., kerning, super- / sub-script) are overrides of the attributes conceived of for the paragraph. This is my argument: I see no reason or benefit to replacing the "Leading" attribute field in the Character panel with a newly invented "Leading Override" attribute field, when the simple act of selecting a word or phrase within a paragraph and altering the leading value already accomplishes a local leading override. But more grating to the workflow of a designer working out ideas for text setting is the elimination of the "Leading" attribute field from the Character panel and moving it to a separate Paragraph panel. For every idea a designer has about a look for a paragraph style, he/she must constantly flip back and forth between two panels.
  2. @Joachim_L Welche Mannschaft magst du lieber, 'Gladbach, Düsseldorf, Köln, Schalke, oder noch etwas anders?
  3. I'm happy to have IDML import. INDD import would be a nice bonus, but more important would be IDML export so that we could have a round-trip exchange format.
  4. @MikeW What you are pointing out is InDesign's contextual toolbar, where the Paragraph and Character panel fields are collected and shown together as one. What I illustrated above are the actual separate Paragraph and Character panels. Moreover, you will note that Adobe does not invent a separate "Leading Override" attribute field in place of the standard "Leading" attribute field. And, the "Leading" attribute field is grouped with "Typeface", "Weight", and "Point Size", precisely in the way that typesetters think about the basic attributes of a passage of text. You'll notice the way Adobe's UI presents one, and only one, "Leading" attribute field. You've illustrated the simplicity of selecting a line or phrase within a paragraph, and using the "Leading" attribute from the Character panel to override the leading value for the paragraph. You will note the "+" appended to the paragraph style name, which signifies that you have locally overridden the leading value for the paragraph. Adobe does it correctly. Affinity has been too clever by half, divided the "Leading" attribute from the "Point Size" attribute, and introduced an unnecessary "Leading Override" attribute.
  5. @MikeW Not true. See below. Leading is leading. Local overrides are achieved by selecting a word or passage and then changing the leading value there. One can record the exception as part of a Character Style.
  6. @walt.farrell This logic make perfect sense in the abstract, which is probably why an engineer who does not set type set it up this way, but does not respect the way that type setters think about and work with type. It breaks the typesetter's conceptual model, introduces unnecessary confusion with a new "Leading Override" attribute field, and introduces the workflow friction point of extra clicks to record the basic idea: typeface, weight, point size and leading.
  7. @MikeW Approaching this from the perspective of a typesetter, and thinking of practice and efficiency, the designer conceives of a basic idea for setting a passage of text. He/she thinks, "This should be set as Avenir Medium, 12 over 14." It's a whole thought. It's foundational for everything else. And so logically, and from the perspective of efficiency, one expects a single panel for recording that thought. Every other design program recognizes this. Affinity forces the designer to break the thought in two parts: 1) record the typeface, weight and point size; 2) avoid the trap of mistakingly recording leading values in the "Leading Override" field; 3) switching over to the Paragraph panel to recored the leading value. It's inefficient, adds an unnecessary step, and introduces an unnecessary "Leading Override" attribute. If one wants to override the standard leading for a paragraph, one simply selects a word or phrase and changes the leading value locally. That's it. Why confuse matters by introducing a "Leading Override" attribute where every designer in the world expects a "Leading" attribute? I suspect that a software engineer with no actual experience in setting type came to the conclusion that leading should be considered a paragraph attribute and therefore divorced it from the Character palette, which is where typesetters expect it to be.
  8. I'm not sure what UX logic drove the decision to place the "leading" attribute in the Paragraph panel rather than the Character panel. Nor do I understand the logic or necessity of converting the "leading" attribute in the Character panel into a "leading override" attribute. However, this UI/UX design runs contrary to the way those who set type think about type setting. I'm writing to request a rethinking here of the Character and Paragraph panels to more accurately reflect the way that designers think about type and type setting; that the "Leading" attribute be removed from the Paragraph panel and that it replace the pointless and confusing "Leading Override" attribute in the Character panel. When designers go about specifying type in documents, the most basic and essential attributes of a type setting idea are typeface, weight, point size, and leading. In most design applications these attributes are presented together in a single character panel. It matches the way designers think about type settings: "Jim, set that passage in DIN Next Regular, 10 over 12". As that is a whole thought, it just makes sense that these basic attributes would be addressed together in the Character panel, leaving the Paragraph panel to shape the paragraph: indents, lines before and after, rules before and after, drop caps, etc. Why force the extra step of flipping to the Paragraph panel to set "Leading"? It's extra work, a point of friction and a cognitive break from the way the designers think about setting type. Moreover, what is the point of the "Leading Override" attribute in the Character panel? It's a very idiosyncratic thing to introduce here in place of the more traditional "Leading" attribute, and serves no apparent purpose. Further, as it is separated from the "Leading" attribute in the Paragraph panel, there's no point of reference for the override value, and it's misleading to designers who are accustomed to specifying point size and leading together. Character styles are where designers would traditionally record a local interruption in the leading of a paragraph. Or, less formally, one would just select a word or phrase in a paragraph and apply a different leading value. The override would be expressed as a "+" symbol appended to the paragraph style name. So, for the sake of the logic with which designer think about setting type, eliminating confusion, and eliminating needless mouse clicks to switch between panels to specify the essential idea of a typeface, weight, point size and leading, please consider replacing the "Leading Override" attribute in the Character panel with the "Leading" attribute, and removing the "Leading" attribute from the Paragraph panel. Thank you for your consideration.
  9. I'm writing to request an enhancement to the existing "Column Guide" feature in Publisher and it's sister applications: the ability to set up irregular, non-symmetrical, and compound column/modular grids for page composition. Presently, it's quite easy to set up regular, symmetrical Column/Modular grids. Dial in four columns, five rows, and a gutter width of 12 points, and you're off to the races. But what if one wanted to customize that 4 x 5 modular layout grid such that the span of the bottom four rows were divided into thirds? That is three rows over the space of what were four rows like the illustration below. Presently, the Column Guide dialogue box doesn't allow for such a configuration. I have found a work around, which I will describe, but the request here is that the "Column Guide" feature be extended to allow for custom grids. My hack, or work around, involves drawing custom shapes on a Master Page layer and ensuring that the "Snapping Candidates" option in the "Snapping" dialogue box is set to "All Layers". This works, but it can be tedious to make the calculations and to place the multiple shapes. The other drawback is that one must remember to set the "Snapping Candidates" to "All Layers". It would be more elegant if the entire custom grid and its visibility were controlled by the View > Show Column Guides command. Below are a few additional illustrations to demonstrate the idea of irregular, non-symmetrical, and compound grids that one might establish for a publication layout.
  10. Initial Words in the Paragraph panel and Paragraph Style panel allow for one level of nested styles. It would be nice if one could specify multiple levels of nested styles. A typical use case is the product name, description, feature list and pricing paragraph seen in product catalogs. The sequence of styles in such paragraphs distinguish types of product information. Formatting such paragraphs manually 100+ times is tedious. Embedding multiple nested styles in a single Paragraph style would make quick work of setting this information.
  11. @Joachim_L Thanks for the reply. I guess we have yet another feature request to add to the pile for the development team. They must be buried by their to-do list. The pace of improvements seems to have slowed.
  12. In Publisher, how would one go about setting a very long table of products and specifications over several pages in a catalog document? I'm thinking that this should work just like the threaded text frames, but I can't find any guidance in the help files or tutorial videos. Thanks for your attention.
  13. Don't know if it's true, but someone told me that Adobe Bridge is free to download and install. No subscription required. That may be your best option for now. Check it out and report back.
  14. If you're on a Mac, don't want to pay subscription prices, and desire a visual design tool that does not require knowledge of HTML, CSS or Javascript, I would recommend that you take a look at Sparkle. https://sparkleapp.com Otherwise, if you don't mind paying subscription prices, I've heard great things about Webflow. https://webflow.com
  15. I don't believe there is a Table tool or panel that is exposed in Designer. However, Designer, Photo, and Publisher all work from the same file format, and so there are two solutions to your problem: Begin authoring your document in Publisher, where you will find a Table tool and panel. Then use the Studio Link feature to invoke the Designer tools for any illustration work you need to do. Begin your illustration in Designer, then select the command "File > Edit in Publisher ..." to take the document into Publisher to add your table(s).
  16. @walt.farrell Okay. Thanks for confirming. This is a UX item that would be worthy of attention.
  17. I've been experimenting with "vector brushes" in Affinity Designer. Having applied various vector brushes in a test illustration, I've gone back to select a particular stroke and discovered that there is no way to inspect the name of the applied vector brush. Or maybe there is a way to identify the applied brush, but I can't find it. If you know of a way to inspect the name of an applied vector brush, please let me know. Thanks.
  18. With regard to efficiency, a small complaint that I have with the Affinity suite in general is that it always requires an extra step to name newly created items like swatches, collections, spare channels, etc. It would be nice, when creating a new item like a swatch or a spare channel, if a dialog box would appear upon the creation of the new item, allowing one to name the new item in one fluid sequence, rather than forcing the user to first create the new item and then go back to reselect the new item, right click, and then select the "Rename" menu item. Thanks for your consideration.
  19. Absolutely love the fact that the IDMarkz app can open InDesign documents and import them directly into Affinity Publisher. That's a huge help. Seems as though, with a little more reverse engineering, Affinity Publisher might be able to import and export InDesign files natively.
  20. Have enjoyed many of the Lockdown videos, but have noticed there are no contributions from book or publication designers using Publisher. Are there no Publisher users worth highlighting, or is it just easier to interest folks with photography and illustration?
  21. @Smileyyy I'm not a video editor, but I've read very glowing reviews of the editing software, DaVinci Resolve, as a terrific alternative to Adobe Premier, After Effects and Audition. Check it out.
  22. @JET_Affinity Plotting points is tedious and more in line with an engineering mindset. Some tasks are suited to careful, surgical point plotting, but for digital illustration which assumes an artists mindset, there should be direct intuitive drawing and painting tools. Natural, direct, efficient, intuitive. As for your complaint about excessive points, that's a software engineer's problem, not an argument against a painting tool that creates freeform vector shapes. Consider the problem Serif had with excessive points for expanded strokes.
  23. @Kuttyjoe I don't see how a flood fill paint bucket would be an advantage here. In the tutorial, the artist was not filling existing vector shapes; he was outlining new shapes with the pen tool before filling them. A Blob brush would enable him to "paint" in the new custom freeform shape with fill directly applied.
  24. Just got done watching the "Lockdown 2020" video: "Speed and motion: illustrating a car in Affinity Designer with Chris Rathbone". One thought occurred to me: when it came time to block in the color, shadows and highlights, having the equivalent of Adobe Illustrator's Blob Brush would be more intuitive to work with and more efficient. The Pen Tool makes sense for line work, but a Blob Brush that "paints" freehand shapes would be better for painting areas of flat color. (https://youtu.be/iMlJrYE8Xo0)
  25. @Jowday One of my pet peeves as someone who started designing for print is the conflation of dpi and ppi. Dots per Inch has always meant the ratio of literal dots of ink per inch applied to a paper substrate, where a high-end image setter could image a printing plate with a resolution of 2400 dpi – not to be confused with the 300 ppi resolution of the raster art being processed. It seems that the definition of dpi was appropriated as an analogy for explaining pixel density of electronic displays. The other pet peeve is the insistence of web and app developers who've never worked in print to refer to the pixel dimensions of an image or screen as the "resolution" of that image or screen. Without a ratio of pixels to inches, nothing is resolved. There is no resolution described or implied by the simple pixel dimensions 800 x 600 px. We simply have dimensions expressed in abstract and relative units. But language evolves. Persistently misused terms become accepted standards.
×
×
  • Create New...

Important Information

Terms of Use | 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.