Jump to content

robinp

Members
  • Content count

    137
  • Joined

  • Last visited

About robinp

  • Rank
    Advanced Member

Recent Profile Visitors

116 profile views
  1. robinp

    v.145 problems

    Well, .157 is out and I can’t see a mention of many of these issues being fixed. The dragging of images from finder now respecting the linked / embedded preference is a welcome fix though.
  2. robinp

    v.145 problems

    Is anyone actually looking in to this? I’m very happy putting effort into reporting bugs to help you guys out but some kind of acknowledgement that it’s been seen or being looked into would seem to be a reasonable expectation. Cc @Ash
  3. robinp

    v.145 problems

    Has this just slipped under the radar @Chris_K @MEB ? If it is something you're looking into it would be nice to just have a quick reply saying you've seen it and are investigating. Thanks
  4. robinp

    v.145 problems

    I should add that the reason some of the object frames look a bit blotchy in the screen shots above is because I deleted out the content after taking the screen shots. The things to look at are the margins and guides.
  5. robinp

    v.145 problems

    Hi Chris Further to the above points, I haven't yet been able to recreate problem "3", nor have I managed to recreate "2.1". With regards to problem 1, see below video. The first time a page is dragged it goes where you expect it. The second time, who knows where it went! page dragging bug.mov Problems 2.2 to 2.4, the issues are a bit more nuanced but mostly still there. This shows the master page (including guides and margins) before changing the document from 'spreads' to 'pages'. Here is one half of the master after the split which shows the margins missing: Here is a page with the margins etc immediately after the split from spreads to pages: Here is the same page after re-applying the relevant master page. Note that all guides and margins have been lost: There are clearly a few bugs here! Robin @MEB @Chris_K
  6. robinp

    v.145 problems

    Look, copy and pasting a linked file around the document would be fine. Copy and pasting a block of text or a frame or even a guide (this is something I've requested previously) all makes sense. I understand what you are saying, why have fewer features? "MORE FEATURES IS GOOD!" seems like a hard position to disagree with, but I'm afraid in this case it is simply wrong in my opinion. Imagine a team of 5, 10, 20 or 30+ all who are contributing to the assembly, artwork and writing of a document. In my field (Architecture) DTP is just one small (but very important!) aspect of our jobs. We have to know many other very complicated programmes which we spend far longer using (and are therefore relatively more expert in). My concern having managed a team of around 10 working towards completing a single document is that you need everyone to be able to contribute without worrying that they are all going to screw up the document. There isn't time, nor does it make sense to spend the time, nor is it likely to stick, to train everyone sufficiently to make sure that an accidental pasting of an image directly into a document is spotted or even avoided entirely. In the event that something like that happening (or a placed image that is embedded) I can just see (from painful experience) that you would discover at 3am that many images in a document haven't been updated to reflect the current artwork as expected because the images were embedded or pasted directly into the document. So while more features may seem that more features is good, sometimes the wrong feature can be worse than not having it. It is quite simple, I want a way to make sure that artwork is only ever linked into the Publisher document. It is quite simple and I'm happy if there are options for allowing hobbyists to mess around being less rigorous / less robust but please please please, allow those of us that work with sometimes large teams to set it up so that a rogue team member can't mess up an entire document without anyone realising.
  7. robinp

    v.145 problems

    You shouldn’t ever do this in my opinion. I guess that’s the point, I’m talking about a professional, team based, workflow. Copy and pasting an image in from another document should never be part of a robust and responsible workflow if your livelihood depends on it. Far too prone to failure and impossible for teams to work together on assembling a document. Maybe being able to do that is a good hobbyist type feature and I’m not saying the app shouldn’t do that. What I’m saying is that I want / need the ability to set Publisher to not allow these kinds of bodging methods. Perhaps a app wide switch to go into ‘pro mode’ would do it?
  8. robinp

    v.145 problems

    Thanks but my point above is that even when a document is set to default to linked it doesn’t actually do it. I’ll give setting a preset a go, that could be useful for some other things. I think really what I want, given the way Publisher seems to want to fall back to embedding is to turn off embedding full stop.
  9. robinp

    v.145 problems

    Hi Chris I'll try to recreate some of the issues and record videos of them. With regards to point 4 InDesign has this info visible all the time in the UI. It is essential when working with potentially 100+ images in a document that you can just check at a glance whether the images are at 100% or say, 50% if you are halving the scale. For example, a A1 drawing at 1:25 scale inserted on to an A3 page would be 1:50 scale (or 50%) which is a nice easy one if inserting to the full extents of the page. If you just want to use an image frame (or crop tool) to focus in on only part of the drawing then you lose that. If you are placing a file and rather than clicking you drag a window to define the size of the inserted file, I have yet to find a way to revert it to either 100% or any known / specified scaling factor. This seems like a major flaw to me; I can't believe we (Architects) are the only ones that need to know and set the size of placed images with certainty. Even if we are, I'd have thought Architect are probably a major target market. I certainly know many are very interested when I've told them about Publisher. Personally, I'd either like this info permanently in the toolbar at the top of the app (there is LOADS of wasted space currently) or at the very least within the transform panel which already has W and H boxes for transform and these accept % figures. I guess all I need is for these to be persistent and relative to actual size rather than the current size. Or at least an option to display them that way. To have to open up the Resource Manager is a non-starter. The window is too obtrusive and unwieldy to have open all the time. I wouldn't be against it being there as well, potentially it could be useful to be able to scroll through all placed files and look out for any weird scaling issues as a QA process before printing. With regards to point 6 (and 5 to a certain extent) I am aware of the option by document. It was set to this yet all the photos ended up embedded. It is just not robust. I want / need to be able to tell Publisher to not accept embedded files full stop. No ifs. No buts. I just don't get why it always seems to default to embedding rather than linked regardless of what you do. It often changes linked files to embedded without being asked. It inserts images as embedded even when the file is set to default to linked. Please either ditch the whole concept of embedded or make it an app preference to not allow embedded files. I appreciate the high quality preview you get by default (vs what InDesign does) and appreciate that this probably necessitates more info being included (embedded!?!) in the file to be able to provide this level of persistent preview, but to inflate files by much more than the sum total of the files inserted seems bizarre and perhaps linked to the flakey embedded / linked behaviour described above? thanks Robin
  10. I experienced a series of problems trying to set up a new document yesterday. I was in a rush so I couldn't report them at the time so apologies if some of the descriptions are not as thorough as they might be: Dragging pages around I the pages panel was incredibly unreliable. Once or twice, the page would move where I had dragged it to. Most of the time it went somewhere completely different. Confusing and is dangerous in that you could unexpectedly end up with a page in the wrong place if you aren't paying enough attention. With a large document you might have to spend quite some time trying to locate the file I created the file by doing a save as of a document set up as a spread. I wanted the new document to not have spreads, but to be a series of single sheets. This split the master page spreads into two. This is fine as might be expected. The problems then started: It seemed to be a bit random as to which pages had which master applied. I would have thought each page should retain the half of the spread master that it originally had The split spread master pages both had the same names (maybe part of the various problems experienced?). I think it would be helpful to append a 'right' and 'left' to each half so that they can be identified in the master pages panel. The guides and margins from the master pages no longer seemed to be applied properly to the pages. Reapplying them did nothing. The only solution was to delete all the pages and then create new ones from the master pages. I know this has been mentioned before, but the pages really need a visual indicator as to which master is applied to which page Creating a new page before another didn't work. It still went to the end of the document Still problems with working with images that are of a particular scale and being able to identify what and how the image has been scaled relative to its 100% size. This is essential for us as Architects. We absolutely MUST know what scale drawings have been inserted at. That applies to images directly placed as well as ones inserted into frames. File sizes are still out of control and despite having the file set to 'linked preferred' for placed files, the files have all ended up embedded. A file with 13 photos is over 120MB. This is nuts. It must be possible to set publisher to ONLY work with Linking rather than embedding. This is going to be a major roadblock to us adopting it fully if this inherent preference to embedding is the final solution for the AP. Otherwise, I am really liking it. Just need to sort out some of this serious issues (the ones in bold) and I think it will be a killer app. Robin @Chris_K @MEB
  11. Hi Chris, I have a 2018 13" MacBook Pro with a 27" Dell U2715H monitor plugged in externally. I suspect it happens because I plug and unplug the external monitor fairly regularly. The secondary windows always appear at the far right of my MacBook screen almost entirely off screen. I have the monitors arranged so that the Dell external monitor is positioned directly above the Macbook screen which I guess is a bit unusual? Edit: I should add that this doesn't happen all the time. Not sure what the cause is but I'll pay attention to what might be the cause. Robin
  12. Hi, sorry, no and now I can't remember which file or spread it was that was causing it. Sorry, I'll try to be better at reporting these bugs!
  13. Hi @MEB Sorry, I've just checked on our back ups and cannot retrieve the version of the file with this problem. If it occurs again I'll be sure to keep the file. Robin
  14. I understand about horizontal scroll bars, but at least the ellipsis solution would at least ensure the text is legible, even if you can't see it all. Looking at it more, it would seem to me that the whole layout could be tightened up drastically. On the example I gave above, given the hierarchical layout, the width given to the style names is only about 1/3 of the whole panel width. Not sure what's going on to the right of it but there is loads of space unused. To the left, I think everything could be tightened up a LOT and the hierarchy would still be legible.
×