Jump to content

Lagarto

Members
  • Content count

    13
  • Joined

  • Last visited

  1. Flexibility is another matter, all professional layout programs must be able to handle multiple color spaces, but there needs to be consistency and predictability, and ease of use when handling color palettes and different color spaces, modes and definition models. There is no point in forcing a single color space for color definitions and palettes (e.g. based on document color mode), but it should be possible to easily see the original (designer-defined, or imported) color definitions used, and convert color swatches from one color space or mode to another in a controlled manner (governed by the document color profile) already at workflow level, if desired (and not just when producing for a specific target); or see how colors are used in the document and remove the non-used swatches, etc. Auto-updating (by user's choice) color swatch names, controlled generation of document palettes with swatch names showing meaningful color values, ability to keep assigned PANTONE swatch assignments as object attributes and add them in the document/app palette, and more informative way of handling tints would be a welcome addition, and something that there will certainly be also in Affinity apps, sooner or later.These kinds of features just add information and usability, and have nothing to do with forcing the designer to use the narrowest possible color gamut (determined by the main document target and device limitations). Sam's post was just one example of problems encountered if and when the designer wants to work consistently with the color. Part of the complexity may be explained by the necessity to switch between "Personas" (Photo, Designer, Publisher), so I fully understand that there are some color issues at this point. But mixed color spaces are handled fluently by all professional page layout applications so having RGB (defined with multiple models like Lab, RGB, HLS, Hex, etc), CMYK, spot colors, and tints mixed in one and the same document palette and seeing predictable results (not just for CMYK colors but for wide-gamut colors like PMS colors) on the screen while also seeing the underlying color definitions at a glance and maintaining full control of the document colors -- is itself nothing new.
  2. You can work around the problem to some extent by creating layers on the master page for each required language, then placing a column text frame in each layer. Then you can hide/show the desired layer on the master page and start flowing text in frames on actual pages that use the master. The layers are copied on each new page that uses the master page, and text frames get auto-generated when you flow the text. You can place additional content within a single language layer (graphics, photos, etc.) by detach editing the master on individual pages so that layers become accessible from within a page. This is a admittedly a bit awkward but works reasonably well at least with simple publications.
  3. Fully agreed. The best way I have found to stick to CMYK (or any other specific) palette is to create a new app or document palette, and then define any new color by using CMYK fields / sliders, and adding them to the document palette.This way you get at least CMYK based swatch names (but then again, if you create the color as a global color, you get just generic names like "Global Color 4" so to be more informative you need to rename the swatches manually). Unortunately ihe names are not automatically updated if the definitions are changed. One might think that working with PANTONE CMYK-palettes would offer a solution but PANTONE-based color assignments made for objects are not reflected back in swatch highlighting, and when added to the palette, get HLS based definitions. Very frustrating. For me this is the most urgent fix I wish to see in Affinity apps. 1.x versions do already have an impressive feature list but if handling of colors and palettes is flimsy, credibility as professional (print production) apps cannot be achieved. Edit: Rather than creating directly a global swatch from a selected color (and getting a non-informative swatch name like "Global 3"), it is better to first create a regular swatch so that you get CMYK values, and then from the context palette, choose "Make Global" This way you can keep the CMYK values in the Swatch name.
  4. The way the color (incl. document and app) palettes work requires some learning but perhaps the complexity is explained by the need to have the tools available across all three apps. It would be nice though to have the kind of functionality InDesign has (optional and by default turned on auto-update of color swatch names, and then manually created tints when percentage of base color is applied to selected object and a new swatch is created so that the percentage is shown after the base color values, and true values as a tool tip). But I understand that this is a complex feature considering e.g. change of color profiles and possible color conversions and adjustments; for version 1.x apps the way the color tools work is already quite impressive and I am confident that they will improve in the future.
  5. I tried to look up if this is posted before but could not find anything: it seems Publisher names swatches according to HSL color model (at least when choosing the color from the palette), and then keeps that name until the user manually renames the swatch, even if the color is edited. While having manually named swatches is often useful and even desired, I hope there would also be an option to update the color name to reflect the current color and tint, and per the color model used to define the color (it seems that the initial name is given according to the color model used to define the color if a specific model e.g. CMYK sliders are used; the default color palette could perhaps reflect the document's selected color model, e.g. CMYK for print documents).
  6. It would be nice to be able to launch an external (default/chosen) editor from this link, as well (similarly as in InDesign or QXP). (Even if much can be done by internal editing tools included in Publisher, or by using,Personas when available.) Or at least a tool that allows locating the file in File Explorer / Finder.
  7. Possibly fixed now. (1.7.1.399). At least in the attached blacks.afpub and the related pdf produced from it the other K100 knocks out while the other overprints. Or perhaps I missed something. blacks.afpub Test.pdf
  8. Ok, no big deal. Did not realize that the text that was imported in the attached file was already converted to paths (while the part thas was not imported was still in text format).
  9. This seems to be currently the only way to do what MickRose asked. It would be useful to have InDesign's "Unthread Text Frames" and "Unthread Each Text Frame" or QuarkXPress's Unlink (under Linkster) kinds of unlinking features also in Publisher. A related improvement would be to have the text flow continuing buttons placed so that they show always (similarly as in InDesign the plus button), even when the text frame is low (now the frame needs to have certain minimum height to show the button, which often means that more than one text row needs to be shown until the text can be flown).
  10. As images can be imported directly onto the pasteboard (off the page), it might be ok to be consistent and allow that also for the text. But if the pasteboard is clipped off (View > View mode > Clip to Canvas) imported elements might easily be left accidentally invisible (placed off the page) so perhaps that's the reason why text frames are created within the page boundaries when dragging and dropping. InDesign does this by loading the texts in the cursor so the user can decide where and at which size to create and place the text frames. Quark creates the loaded text frames at the point the user clicks when dropping the files. As APub allows importing multiple text files by loading them in the cursor (similarly as InDesign) and then placing them one by one whereeer and at the size the user chooses, this could be supported also when dragging and dropping text documents. There is good use for creating and placing text elements off the page, e.g. when importing multiple tables, captions, and other elements which for one reason or another are kept in separate files. This way you can e.g. format all such elements in separate frames (placed at locations, sizes and order you wish) but in one go off the page and place them on the pages only after that, without messing up the current layout. Edit: It seems that if MULTIPLE text files are dragged and dropped, the generated text frames CAN be placed off the page and on the pasteboard, so this seems to be a genuine bug. If a single file is dropped, it must be dropped within the page boundaries, otherwise nothing happens. As an afterthought, it is a good feature to autogenerate text frames directly at the spot the user points, since the alternative method, placing via loaded cursor, is supported when using Import via menu command. This way the user can pick the desired method according to use. E:g., dragging and dropping 100 or so caption text files with autogenerated text frames can be very useful since it is possible to format all text frames in one go and then fit the frames. This way it is not necessary to manually create text frames for each imported file.
  11. See attached Publisher file, page 4. It has a yellow diamond shape that is part of the "English text" layer created on a master page. The object was created on page 4, where it is automatically placed outside of the master page layers, but then manually cut and pasted within the text, so that it gets embedded in the master page's English text layer. The objet can subsequently be defined as inline/non-inline, and its wrap settings can be specified. Everything works fine until I make some changes on other pages (at least on the master page, e.g., set the "English text" layer invisible, etc.). When I come back the diamond shape can no longer be selected (other than from the Layers palette, but while the selection rectangle appears, nothing applied to the "selected" object itself takes effect, and the object cannot be deleted, either). Another problem is that the shape's text wrap settings affect to text on other layers, even if the layer containing the shape is hidden on the master page. The file is an experiment to try to work around the problem of not having global layers available (so this is simulated by creating layers on the master page with linked text frames that allow the layer to automatically be copied on multple pages, and set visible/invisible in one go in the whole document), so probably not "intended use". But if the mentioned problem could be fixed, this would be a clever way to have graphic objects included on master page layers (but NOT as an object on master page itself) as non-inlined objects (as if anchored to the text frame). EDIT: Noticed afterwards that this is intended behaviour. It is possible to edit the "ghost" object by selecting the Master page item on the Layers palette of the related page and then choose Edit detached from the context menu. This is actually a very useful feature and helpful when trying to simulate behaviour of global layers. The text wrap problem however still exists (ot at least I have not figured out yet how to disable the effect). test_03.afpub
  12. Text on path in a FreeHand v11 file is only partially imported. See logo_freehand_ENG.FH11 (the file opens correctly in FreeHand MX, and also in Affinity Publisher when saved in AI format). A minor feature miss but just to let you know... (Unbelievable that FreeHand files are supported -- not that I have much use of the feature but I recently had to install FreeHand MX just to be able to import the attached file in an InDesign document -- Adobe Illustrator does not open it, nor does QuarkXPress. This shows some level of culture and professionalism!)
  13. It would be useful to have a feature that allows searching formatting exceptions e.g., find font size using Body text paragraph style that is NOT 10 points. Microsoft Word has a feature that allows searching NOT bold and NOT italics text formatting but this could be extended to additional formatting features, font size, font family etc. In InDesign font size exceptions can easily be checked by setting a greeking font size to appropriate threshold value and then using zoom factor that shows part of the text greeked and part non-greeked, or you can search for the formatting (e.g. font size and font family) that certain text parts like body text SHOULD have, and see if there are breaks in highlighted found text, but this is tedious if there are logical formatting exceptions like per character style formatted smaller font sizes amidst the body of the text, so having directly a feature that allows "negative" search would be highly valueable.
×