Jump to content

anweid

Members
  • Content count

    92
  • Joined

  • Last visited

Everything posted by anweid

  1. The German Affinity Publisher 1.8.0.502 (and previous versions) behaves as follows: Bulleted lists can easily be created with custom bullets. With a dedicated character style, it is even possible to make the bullets very large and position them much below the baseline, without changing the leading of the 'real' text. Wonderful. The attached screenshot uses a 10pt font, and the hand bullets are 40pt with a baseline offset of 14pt. This is exactly how it should look. Fine. But when selecting some text in this bulleted paragraph, the selection marker itself vertically extends from descender to ascender of the very large bullet (instead of the selected text), which is rather confusing. In the screenshot, the word 'the' is currently selected. It would be nicer if the selection would only extend to the dimensions of the selected text itself. Andreas Weidner
  2. Ah, that's a good idea - thanks. I still think that the mentioned behaviour is a bug, but at least this workaround helps me to continue writing for the moment. Andreas Weidner
  3. The German Affinity Publisher 1.8.0.499 behaves as follows (see video): A text style is used defined with an exact line distance of 15pt (0:00-0:10). Inside the text is an SVG graphics pinned as a character with an offset of 0pt from the base line. If the pin offset is now increased, the SVG moves down, which I find counter-intuitive: It would be more logical if increasing the offset would move the image up. But this is not the main point... The main point is that when increasing the offset to a positive value, the line distance to the next paragraph (which is also defined with an exact height of 15pt) suddenly also increases, which is not intended (0:10-0:19). This already happens if the graphics is still inside the range of the font's descender, which is even more unintended. If the offset is negative (0:19-0:31), the graphics nicely moves upwards without disturbing the line height, which I find wonderful. It would be nicer if changing the offset of a character pin would behave the same for both directions, at least in case of a well-defined line height. Andreas Weidner PinOffset.mp4
  4. This also happens in version 1.8.0.502, which I just found...
  5. In the German Affinity Publisher 1.7.3.481 (Windows), underscores in file names are not correctly shown in the Resource Manager: Instead of showing the underscore as a separate character, the character following the underscore is underlined (as is usually the case with keyboard shortcuts). Andreas Weidner
  6. Please ignore the above post. The issue already seems to be corrected in the current beta (I should have checked that before posting). Andreas Weidner
  7. The German Affinity Photo 1.8.0.486 (and its predecessors, and all other Affinity programs, and in fact all other Serif programs including PhotoPlus 8) simply dies silently when trying to load the attached JPG image of size 12128*1888. All other programs that I ever tried can load it without any problems (including Microsoft Paint). It would be nice if Serif programs could also manage that. Andreas Weidner 20191027_115327.jpg
  8. This is quite probably by design, but I still call it a bug, because it represents a painful user interface: Affinity Designer 1.7.3.481 (Windows) is loaded with a long table of words to auto-correct in various languages. A few 'words' are useful, like '(c)', '1/2' or 'mm2', but the overwhelming majority is rather useless. Trying to auto-correct every typo that might possibly happen is not such a good idea. Therefore, I want to get rid of 95% of that list. Unfortunately, it's impossible to select more than one entry at the same time, neither the Add nor the Delete button seems to have any keyboard shortcut, and after selecting an entry by clicking on it, and clicking Delete, the selection does not move up or down, but just disappears. This means that I have to click hundreds of times to get rid of most of that list. It would be much nicer if the above three things were implemented (multi-selection, button shortcuts, selection moving). Additionally, the same behaviour could be implemented for the other lists of the Settings dialog (abbreviations, title exceptions). Andreas Weidner
  9. That's an idea. Let's try... Andreas Weidner panorama.zip
  10. Affinity Designer 1.7.x on Windows allows the insertion of (time and) date fields with different formatting, which is nice. Unfortunately, the format that I myself need in around 90% of the cases is not available yet (or at least I couldn't find it). It would be nice if you could include the format for international display of dates, meaning YYYY-MM-DD (with non-breaking hyphens). Today's date would therefore display as 2019-10-12 (12th of October). Thanks. Andreas Weidner
  11. After downloading the picture attached to the above post, I also cannot read it with any program anymore, because it seems to have become corrupted either by uploading or by downloading. Please tell me how to send you the original file, bypassing this forum. I managed to read the original image with SnagIt, Directory Opus, ImageGlass, Paint, Edge, LibreOffice, XnViewMP, InDesign CS5.5, PDF24. I had problems with Serif products, FireFox, TextMaker. Andreas Weidner
  12. The German Affinity Publisher 1.7.3.481 for Windows, when used in conjunction with German language text, behaves as follows when using auto-correction: When the option Capitalise the first character of sentences is switched on, the character combinations 'fr.', 'sa.' and 'so.' are capitalised anywhere in the sentence (into 'Fr.', 'Sa.' and 'So.'). The first two are not so problematic, because words like that don't exist in German, but the latter is a valid word that can end a sentence. E.g., the correct sentence 'Das ist so.' (which translates into 'That's so.') is auto-corrected into 'Das ist So.', which is not correct. It might be that this is due to the above three combinations being abbreviations of some German days of the week, but the others ('Mo.', 'Di.', 'Mi.' and 'Do.') do not behave that way. When the option Capitalise the first character of sentences is switched on, the character combination 'apostrophe + lower-case s + dot' ('s.) is auto-corrected into 'apostrophe + upper-case s + dot' ('S.). Independent of the fact that this combination is very rare in German (as opposed to English), the auto-corrected result is never used in German. When switching to British English, no correction is done (which is wonderful and should also be the case for German). Both of the above corrections are wrong, anyway, but they also do their corrections at a place that is not the first character of any sentence, which seems to be additionally out of place here. Andreas Weidner
  13. Well... Of course you could reduce the abbreviations list, but that would still leave the bug that some character combinations might be capitalised that do not appear at the beginning of sentences. The above auto-correction should only capitalise words that really do appear at the beginning of a sentence, but not elsewhere. Andreas Weidner
  14. anweid

    Hyphenation bug with slash?

    This not only happens with a slash, but also with other characters. The German Publisher 1.7.3.481 under Windows hyphenates also directly before bullets. The attached screenshots (never mind the bad justification and kerning) tells the reader of the original document which menu entries to select, and I decided to separate the menu levels with bullets. The strange hyphenation comes from Publisher. For the second image, I also tried the characters ¼®¥Φϖ☺ (instead of the bullet) just for fun, and each and every one of them makes the same hyphenation happen. Unfortunately, since standard hyphenation algorithms normally only look up the probability of hyphens between pairs of characters, and the above characters probably never appear in any pair list, I don't have any idea how to solve this. The problems with the slash should be solved somehow, though, because slashes appear rather often... Andreas Weidner
  15. With the German Affinity Publisher 1.7.3.481 (Windows), as soon as I do lots of things to make pinned objects behave properly (mainly in a double-sided document with mirrored margins), I get random crashes: Publisher just vanishes without trace, without error message, without anything. And the reason why I sometimes have to do lots of things with pinned objects is that there seems to be a number of odd tweaks in the implementation that make pinned objects behave strangely or unexpectedly, so lots of fiddling is involved. Since this happens randomly and on more or less all files I tried, I cannot send you an example file, but just rant a bit. Documents without pinned objects don't regularly produce crashes (as far as I remember). Andreas Weidner
  16. All Affinity programs use descriptive icon texts for the tool bar that at one point are misleading. See the attached screenshot: For the (z-)reordering of layers, the word Anordnen is used (1). That's good. For aligning objects, the word Ausrichten is used (2). That's fine. (3) also aligns objects, but unfortunately is translated as Anordnen, which means something else. To prevent misunderstandings, (3) should also be called Ausrichten. [nitpicking warning] (4) shows up as Zentriert, which is perfectly understandable and clear, but doesn't have the same wording as the other two horizontal alignment texts next to it. For textual consistency, I would prefer the text Zentriert ausrichten or, if a shorter text is desired, Zentrieren. Andreas Weidner
  17. This is what I meant with (3) above: This button should better be called Ausrichten to be consistent. I realised this problem exactly because suddenly, two groups with the same text appeared in the toolbar... Andreas Weidner
  18. The document where the problems mainly occur uses some fields in the master page's footer (author, savedate, filename, pagecount), and nowhere else. Publisher also crashed once when trying to open this document, but I also couldn't force that error again... Andreas Weidner
  19. The German Affinity Publisher 1.7.3.481 (Windows) makes it sometimes very difficult to select pinned objects (see video): The file contains a bit of text, a bitmap pinned as a character, a pinned text on top of it and two vector objects at the right. The vector objects can easily be selected via mouse clicks (0:00-0:08). Fine. With Alt+Click on the circle, Publisher nicely cycles through all objects at that position (0:08-0:20). Fine. When selecting the bitmap, Publisher changes the cursor to a black one, which apparently makes it possible to move the image like a character. Selecting the topmost text is not possible anymore, because clicks on the small text frame are now consistently ignored (0:20-0:30). Though this might be by design, I would find it more logical if a click on the topmost object would select it properly. Unfortunately, even Alt+Click on the topmost text frame (or even the bitmap itself) does not cycle through any objects anymore. The selection is thus stuck. The only possibility to get out of this sticky mode is to select something different, and then click on the topmost text again (0:30-end). It would be nice if at least Alt+Click would cycle through objects under these circumstances, and even better if a click on the topmost object would again select it as usual. Andreas Weidner PinSelection.mp4
  20. This of course would be the best possibility: Everybody could get their own wonderful settings... Andreas Weidner
  21. Affinity Publisher 1.7.3.x seems to always display all defined text styles in its Text styles studio. This often makes styles show up there that I will never need again, e.g.: I define header and footer styles for the master pages, but after the master is defined, I don't need those styles anywhere else in the document. I define index and contents styles once to make things look nice, but will never use such styles myself outside the index or the table of contents. It would therefore be nice if the text style dialog would also support the hiding of text styles in the studio, so that this doesn't get cluttered up so quickly. Thanks. Andreas Weidner
  22. As a matter of fact, I liked InDesign up to version 5 and stopped using it after an update to 5.5, because it was extremely buggy and crashed around 50 times a day. But - and this was a good thing - it never, ever corrupted any of my files, even with the largest number of crashes I had in any program I've ever seen... Andreas Weidner
  23. Aha. Then I don't understand that button at all: This button seems to be the only possibility to make the 8 circle handles around an object (meaning adjustable) to change into crosses (meaning non-adjustable). This is not a global setting, but one that is defined for each pinned object, because an object that I define as adustable stays adjustable (circled), and a non-adjustable one also stays that way (crossed). The only way I can understand this is that it is an object property. The eight handles around an object always appear to correctly reflect the current status of this object's adjustability, independent of the state of the checkbox. It's just that the state of the checkbox does not reflect any selected object, which sometimes makes it necessary to change the checkbox twice in order to change the object's state. But anyway: This property is definitely not saved on disk, because after saving and loading, everything is adjustable again. This is all excruciatingly complicated and illogical for me. I suggest the following: If the adjustability should be a property (I would like that, as it can prevent accidental moving), please make the checkbox correctly reflect the selection, and save and load the property to file. If the adjustability should not be a property, please don't make objects keep their adjustability independent of the current state of the checkbox. Andreas Weidner
  24. In the German Affinity Publisher 1.7.3.481 (Windows), the Pin studio does not correctly show each object's status for Manuelle Position schützen (I don't know how this might be called in English). See attached video: At 0:00, the selected frame shows crosses at its surrounding rectangle, but Manuelle Position schützen shows it is deactivated (which is wrong). Going through all other pinned objects (0:05-0:17) shows them with adjustable circles at their surrounding rectangles, and Manuelle Position schützen still shows they're deactivated (which is correct here). Clicking again on the first frame still shows Manuelle Position schützen as deactivated (which is wrong). Now deactivating Manuelle Position schützen manually (0:20-0:25) doesn't change anything for the frame, but at least now the state of the Pin studio is correct. Now clicking on all other pinned objects, the Pin studio shows Manuelle Position schützen as activated (which is right). It seems that the Pin studio doesn't correctly reflect the status of the selected object's Manuelle Position schützen, but just shows the state when the check box was last changed. Ideally, the check box state should be properly updated with each selection. Andreas Weidner PinProtection.mp4
  25. I just destroyed one of my original images on disk due to a very nasty behaviour of the German Affinity Publisher 1.7.3.481 (Windows). This might be by design, though, but it is very dangerous, so I consider it a serious bug, whether or not the programmers think so or not. In the attached video, Publisher is in front, and my file manager in the background: Load a bitmap image and place it (0:00-0:11). Fine. With the resource manager, embed the image (0:11-0:22). Fine. Edit this picture (0:22-0:28). It is wonderful that this is now possible (I was hoping for this function, and now it's available). The picture opens in a separate tab. Fine. In order to change the image's pixels, change to Photo Persona and draw stuff (0:28-0:38). Fine. Now close the image tab. A question pops up asking whether or not I want to save changes. Of course I want to do this, because it's an embedded image, so nothing bad can happen (0:38-0:45). Fine. Unfortunately, now everything is completely screwed up (0:45-0:55): The embedded image is not changed in any way, but stays as it was before the editing. Instead, the original image on disk was changed (as shown in the file manager). Another editing of the picture can not be done anymore, because the Edit button is hidden now. Ooops! I can perfectly understand this behaviour in the case of a linked image. But this image was embedded, and editing this should only edit the embedded image, and not the original on disk. I suggest the following: At least change the warning text: Currently, it reads Do you want to save changes?, which is definitely not enough. It should read Do you want to save changes to the original file on disk? Make this changed message only appear for linked files. In the case of embedded files, ask the question Do you want to save changes to the embedded image?, only work with the embedded copy, and do not change the original. Andreas Weidner PS: Fortunately, the destroyed original was not an important file, so no real harm was done. But it could have been... EmbedProblems.mp4
×

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.