Jump to content

Luca H

Members
  • Content Count

    7
  • Joined

  • Last visited

About Luca H

  • Rank
    Newbie

Profile Information

  • Location
    Germany

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi As already requested by you and (among others) here, here and here I also cast my vote on this issue. It would help me a great deal with organizing UI Kits with several color themes!
  2. My current workflow is to use the grid only as a rough estimate where the object should be placed and then enter / calculate the correct position in the transform panel. The test showed that snapping is not 100% accurate. On the y-axis the snapped object was 0,000086 pt off in comparison to the mathematically placed object. So snapping is not an option. On top comes the inacurate rendering of the grid. Both grid rendering and snapping are not 100% accurate so I stopped using the snap to grid and only use the grid as a guide to see where an object would be roughly placed.
  3. We're actually trying to do something in this level of precision. 😅
  4. For this I did a test: 1. I created a rectangle. 2. In the transform panel I set the size of the rectangle to exaclty the size that one grid unit should have. 3. I snapped the object to the grid at a magnification of 300%. It seems to have snapped perfectly. 4. I zoom to 10.000% and I can already see that it's not placed perfectly on the grid line. Zooming even further makes the problem more visible. 5. Now since I work with a grid and I know my numbers and the sizes of everything I can compare in the transform panel if my object is placed correctly, even if it doesn't appear to be. So one object (as well as a grid unit) has the dimensions of 22,000000 pt x 13,596748 pt. I snapped the object in the 4th grid unit from left and the 4th grid unit from the top. That means the X cordninate of the object should be 22pt x 4 = 88pt and the Y coordinate should be 13,596748 x 4 = 54,386992pt. The attached screenshot shows that it snapped perfectly on the X axis, but on the Y axis it snapped at 54,386904 pt which means that there is a difference of 0,000086 pt. So to conclude the snapping did not work correctly. Also Interesting to see is that when the Y axis is set to the correct calculation (54,386992pt) the object still doesn't correctly sit on the grid.
  5. Hello everybody, before I start to decribe my problem I want to say thanks, that it is possible at all to work with such precision, it does really make a difference to the quality of the work I produce and it's exactly the reason why I switched to working with the Affinity Apps! Now here's the problem: I am currently working with a high-precision document where the decimal places for unit types are set to level 6. In this document I have created a rectangular grid, which is also finely calculated with 6 decimal places. If I now want to align objects to this grid, I run into a problem with the rendering of the grid. The objects do not snap in the middle of the grid line, but somewhere on the side of the line. However, this becomes visible only at an extreme magnification. The problem is, if I place objects with the size of a grid unit directly underneath each other, at some point they will no longer lie on the grid, because this minimal shift causes the objects to protrude further and further beyond the grid lines. On top of that some other questions arise. When I zoom to the maximum magnification everywitng I created turns white but what I believe to be the actual grid line (I did not create any guide lines) becomes visible in blue (however this is only true for the vertical grid line). Yet it is not possible to align objecty perfectly with this grid line either. And as you can see the grid lines don't have the same width.This is not really an issue if the objects snap correctly but it looks like it could be related to this problem. In used Metal as a render engine. I also tried OpenGL, but the problem was not solved. I attached some screenshots (sorry for the ugly colored text) and a demo file so you can recreate the problem. So that leaves me with the question, is there anything I can do? If not it would be very important for me to have this problem fixed, since my work depends on this. Thanks in advance. Luca My setup: macOS 11.0.1 MacBook Pro (15 Inch, 2019) Processor: 2,6 GHz 6-Core Intel Core i7 RAM: 16 GB 2400 MHz DDR4 Grafics: Radeon Pro 555X 4 GB Affinity Publisher 1.8.6 (also checked on 1.9.0.857) Demo File.afpub
  6. Just tested it with the newest beta of Publisher (1.9.0.857) and the problem is fixed 👍 Thank you!
  7. Hi everyone, I think I've run into a bug or some sort of problem with "remove line breaks " in the table of contents settings. Generally this functionality works as intended, when I manually set line breaks they are in fact removed in the table of contents. But for a new project I created headlines that are automatically numbered through the bullets and numbering settings in the text styles. And those numberes are seperated from the text by a line break. This line break is inserted in the "Text" field of the bullets and numbering settings. So it is automatically applied. When I do this, the Table of Contents does not remove the line breaks, which I whish it did. I think it's a bug, but maybe it's supposed to work like that? Is there anything that I can do? I use the latest version of Publisher (1.9.4) on macOS 10.15.7 Thanks in advance, I hope my description of the problem was understandable. Luca PS: In the uploaded pictures it's not possible to show that there was a line break inserted in the "Text" field in the bullets and numbering settings, beacuase there is no visual indicator for that.
×
×
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. 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.